3 ms·

Assembly is so far from the original code written today that it is not even feasible to think about. That being said, imagine how fast everything would be if th

by XCSme 3y ago

Assembly is so far from the original code written today that it is not even feasible to think about. That being said, imagine how fast everything would be if the companies developing the software would actually care about performance. For like 99% of websites and software today, if anyone cared about the app performance, I am pretty sure most would be able to achieve at least 50% speed-ups through very basic changes (correct caching, optimizing assets, replacing bloated 3rd party libraries with a basic native call that does the same thing, configuring the servers and databases properly, etc.). EDIT: That being said, I am pretty sure in a few years AI would be able to provide one-click optimizations to a repository that would either apply best-practices or rewrite the original code in performant Assembly.

jodrellblank 3y ago
> "if anyone cared about the app performance, I am pretty sure most would be able to achieve at least 50% speed-ups through very basic changes" See https://danluu.com/octopress-speedup/ https://danluu.com/octopress-speedup/ > "This blog is a static Octopress site, hosted on GitHub Pages. Static sites are supposed to be fast, and GitHub Pages uses Fastly, which is supposed to be fast, so everything should be fast, right?" followed by > "I'm not sure what to think about all this. On the one hand, I'm happy that I was able to get a 25x-50x speedup on my site. On the other hand, I associate speedups of that magnitude with porting plain Ruby code to optimized C++, optimized C++ to a GPU, or GPU to quick-and-dirty exploratory ASIC. How is it possible that someone with zero knowledge of web development can get that kind of speedup by watching one presentation and then futzing around for 25 minutes? I was hoping to maybe find 100ms of slack, but it turns out there's not just 100ms, or even 1000ms, but 10000ms of slack in a Octopress setup. According to a study I've seen, going from 1000ms to 3000ms costs you 20% of your readers and 50% of your click-throughs. I haven't seen a study that looks at going from 400ms to 10900ms because the idea that a website would be that slow is so absurd that people don't even look into the possibility. But many websites are that slow!"
winter_blue 3y ago
> For like 99% of websites and software today, if anyone cared about the app performance, I am pretty sure most would be able to achieve at least 50% speed-ups through very basic changes (correct caching, optimizing assets, replacing bloated 3rd party libraries with a basic native call that does the same thing, configuring the servers and databases properly, etc.). I'd say a big factor to include here is the choice of language. Going from Python/Ruby to Kotlin/Rust/etc could probably yield a speed up of over 10x / over 1000%.
- XCSme 3y ago
  I think the ecosystem is more important than the programming language. You can choose any language, if you bloat your application with 20MB JPEGs, 3rd party API requests that take tens of seconds or implement animations that take seconds to complete, the language won't matter that much. I am not sure if there are languages that come with a fool-proof ecosystem when it comes to implementing things and making them fast. The only one I can think of are UI-based applications builders, that only allow you to add to your app only a limited subset of UI elements or features.

by XCSme 3y ago

jodrellblank 3y ago

> "if anyone cared about the app performance, I am pretty sure most would be able to achieve at least 50% speed-ups through very basic changes" See https://danluu.com/octopress-speedup/ https://danluu.com/octopress-speedup/ > "This blog is a static Octopress site, hosted on GitHub Pages. Static sites are supposed to be fast, and GitHub Pages uses Fastly, which is supposed to be fast, so everything should be fast, right?" followed by > "I'm not sure what to think about all this. On the one hand, I'm happy that I was able to get a 25x-50x speedup on my site. On the other hand, I associate speedups of that magnitude with porting plain Ruby code to optimized C++, optimized C++ to a GPU, or GPU to quick-and-dirty exploratory ASIC. How is it possible that someone with zero knowledge of web development can get that kind of speedup by watching one presentation and then futzing around for 25 minutes? I was hoping to maybe find 100ms of slack, but it turns out there's not just 100ms, or even 1000ms, but 10000ms of slack in a Octopress setup. According to a study I've seen, going from 1000ms to 3000ms costs you 20% of your readers and 50% of your click-throughs. I haven't seen a study that looks at going from 400ms to 10900ms because the idea that a website would be that slow is so absurd that people don't even look into the possibility. But many websites are that slow!"

winter_blue 3y ago

> For like 99% of websites and software today, if anyone cared about the app performance, I am pretty sure most would be able to achieve at least 50% speed-ups through very basic changes (correct caching, optimizing assets, replacing bloated 3rd party libraries with a basic native call that does the same thing, configuring the servers and databases properly, etc.). I'd say a big factor to include here is the choice of language. Going from Python/Ruby to Kotlin/Rust/etc could probably yield a speed up of over 10x / over 1000%.

XCSme 3y ago
I think the ecosystem is more important than the programming language. You can choose any language, if you bloat your application with 20MB JPEGs, 3rd party API requests that take tens of seconds or implement animations that take seconds to complete, the language won't matter that much. I am not sure if there are languages that come with a fool-proof ecosystem when it comes to implementing things and making them fast. The only one I can think of are UI-based applications builders, that only allow you to add to your app only a limited subset of UI elements or features.