4 ms·
This is what happens when you have a leaning tower of abstractions, with each layer being developed with a philosophy of, "it's good enough". Some performance l
by kitsunesoba 3y ago
This is what happens when you have a leaning tower of abstractions, with each layer being developed with a philosophy of, "it's good enough". Some performance loss is unavoidable when you're adding layers, but that aforementioned attitude of indifference has a multiplicative effect which dramatically increases losses. By the time you get to the endpoint, the losses snowball into something rather ridiculous.
- dumdumchan 3y ago[flagged]
- the_overseer 3y agoIs this missing an /s?
- deleted 3y ago[deleted]
- snovv_crash 3y agoIf you disable the virus scanner and write a simple SDL app on Windows it will open instantly as well.
- LanceH 3y agoAlong those lines, I have numerous clients who just want plain Ruby on Rails -- no react front end. They are all business to business, or at least professional users on the end. They just want their data loaded and to work with it. Ruby on Rails may not be the poster child for speediness as things get big or complex, but if you aren't fighting the ORM, it's consistently quick from click to data. Also, RoR is definitely not dead.
- ecshafer 3y agoRuby on Rails is plenty fast, especially with Turbo. The biggest RoR speed drop is n+1 queries imo.
- viraptor 3y agoWhich is not a RoR issue. You get those accidentally if you write plain SQL as well. (Actually passing the AR query fragments makes the n+1 easier to avoid in complex situations)
- Arwill 3y agoEach level of abstraction has its own caching and buffering routines because the underlying layers are slow, and without the ability to make them better, you can only put your own cache on top of it. This helps initially, but in the end, the time goes wasted managing all those caches and buffers at every given layer.