6 ms·

Only at the scale of the big tech companies do the machine costs start to seriously stack up against the labor costs. (Well, also smaller machine learning shops

Only at the scale of the big tech companies do the machine costs start to seriously stack up against the labor costs. (Well, also smaller machine learning shops, but they are in trouble anyways.) And I don't think they fsce enough competitive pressure to be forced to take the massive foundational and educational investments they would need to pull this off. It won't happen with this generation of the industry.

ineedasername 6y ago
The tooling infrastructure of code development itself needs to be optimized (not necessarily in speed terms) to provide coders with the information & tools necessary to write faster code. It seems like IDE's are currently optimized to facilitate rapid code development, but not development of rapid code.
- est31 6y ago
  The issue is, most code only runs so few times that it doesn't really matter. Only when the code requires so much cloud resources that it's worth to spend an engineer's salary for a few hours/days to optimize it you should do it.
  - adrianN 6y ago
    Or if your software aims to be successful on end-user devices. Only because you don't pay for the electricity or the faster machines, that doesn't mean that no carbon is emitted for producing them.
    - est31 6y ago
      Slack is extremely slow and sluggish. Outside of the hn bubble, people seem to care more about features than about speed or carbon use. That being said, there are areas where users care about speed. For example, FPS is very important to gamers, so games are often highly optimized.
      - adrianN 6y ago
        And cars are way too heavy. Just because users don't care about it, that doesn't mean that it's not important.
      - pdimitar 6y ago
        Many users are not aware that software can be made faster so they don't complain. They simply assume that's how things are.
  - imtringued 6y ago
    That excuse is fine in theory. In practice it's overused in places where performance actually counts.
- xellisx 6y ago
  I use PHPStorm and a plugin called EA Inspections that will gladly point out optimizations. I deal with a lot of legacy code written 10 years ago that I've been slowly optimizing when possible. Of course we've been working to burn down the legacy code base.
  - ineedasername 6y ago
    With respect to legacy code, it's interesting: I work a bit with ERP systems, and 10-year old legacy code from them is often significantly slower than the 25/30-year old legacy code in a prior ERP version from the same vendor. I think it shows that when developers are forced to work within tighter operating limits, they figure it out.
    - xellisx 6y ago
      Yeah, it a shame people say screw doing slightly more work to make a system as efficient as possible. Even some stuff like using $i++ vs ++$i. While, it only shaves one op code per pass, but it doesn't cost any time to type it out. Also people underestimate SQL indexes.
      - ineedasername 6y ago
        Indexes are actually one of the reasons the old code ran faster. Or the equivalent for that database type: I forget what it was called, but it wasn't relational. It was some type of file-based system where a file could be like a normal table, but it could also have "segments", where each segment might have a one-many relationship with the primary segment. Or you might "join" one file to sub-segment of another file, never going through the primary segment. So that was a factor, but so was the fact that the entire subsystem was pretty much written in COBOL, though I would occasionally write small C programs to work around limitations. Even newer versions of the ERP had a lot of the old COBOL still in it, just with a shinier new interface, but they were gradually replacing that code with (I think) Java. Probably because of the ability to keep finding & retaining COBOL talent, along with the need to make the product more readily interfaced via the web rather than a custom presentation layer from the vendor. (which was a green-screen terminal based interface, and significantly faster than any interface you'd see today. And with modern terminal emulators you weren't limited to green, you could choose any color! )
- Narishma 6y ago
  Dev tools themselves are often super bloated and slow, requiring tons of memory and storage, so maybe we should start with those.
awinter-py 6y ago
you may be right for consumer-facing functions where adding more boxes is cheaper at small size but slow internal tools are a direct tax on developer productivity this is an area where faster / smaller software does make a difference
smabie 6y ago
Most of the software that I use I would consider to be unacceptably slow on my top of the line workstation: emacs, webbrowsers, intellij; the list goes on and on. Something needs to be done, and fast. Pretty much everyone I know regularly complains about how slow and crappy the software they use is, especially my non-technical friends. We need to start thinking about performance as a necessary and basic feature, not some nice to have that can be worked on later. A new program needs to designed from the ground up to be fast, from the language choice to the data structures. And I think this shift is being made, except in web development circles. Most new and upcoming languages list performance as a basic feature: Rust, Julia, Nim, Zig, etc. Also, native compilation is often listed as a feature, as there's been a huge backlash against the vm cargo cult on the late 90s and 2000s.
- throwaway_pdp09 6y ago
  What's your problem with your emacs? Mine runs pretty snappy. Sometimes you get a runaway process in it which may be a problem but if you have problems every time, something else is wrong. As for browsers shrug, turn off JS and add a blocklist and it'll run an order of magnitude faster.
  - rjsw 6y ago
    I didn't even feel that emacs was slow when I was running it on a 25MHz 386DX. The only real change between then and now is that I'm using a TrueType font with it.
  - smabie 6y ago
    > What's your problem with your emacs? Mostly, company-mode lags when given a large autocomplete list. Also, large CSV files take a while to load.
    - throwaway_pdp09 6y ago
      First I've heard of company-mode, thanks for that. A DDG search gives https://company-mode.github.io/ https://company-mode.github.io/ as its first result, on their it refers you to its issue tracker - perhaps let them know if you haven't already? Large CSVs, Perhaps use LFV (large file viewer) if you want a read-only look. Otherwise I just loaded a 26MB binary file in less than a second. I created a 2.46 Gigabyte (not MB) CSV, opened it in a new emacs, took less that 15 seconds (fundamental mode). I think your problem lies elsewhere - it may be an unnecessary mode being invoked. How did the browser run when you turned off JS, a whole lot faster I imagine?

ineedasername 6y ago

The tooling infrastructure of code development itself needs to be optimized (not necessarily in speed terms) to provide coders with the information & tools necessary to write faster code. It seems like IDE's are currently optimized to facilitate rapid code development, but not development of rapid code.

est31 6y ago
The issue is, most code only runs so few times that it doesn't really matter. Only when the code requires so much cloud resources that it's worth to spend an engineer's salary for a few hours/days to optimize it you should do it.
- adrianN 6y ago
  Or if your software aims to be successful on end-user devices. Only because you don't pay for the electricity or the faster machines, that doesn't mean that no carbon is emitted for producing them.
  - est31 6y ago
    Slack is extremely slow and sluggish. Outside of the hn bubble, people seem to care more about features than about speed or carbon use. That being said, there are areas where users care about speed. For example, FPS is very important to gamers, so games are often highly optimized.
    - adrianN 6y ago
      And cars are way too heavy. Just because users don't care about it, that doesn't mean that it's not important.
    - pdimitar 6y ago
      Many users are not aware that software can be made faster so they don't complain. They simply assume that's how things are.
- imtringued 6y ago
  That excuse is fine in theory. In practice it's overused in places where performance actually counts.
xellisx 6y ago
I use PHPStorm and a plugin called EA Inspections that will gladly point out optimizations. I deal with a lot of legacy code written 10 years ago that I've been slowly optimizing when possible. Of course we've been working to burn down the legacy code base.
- ineedasername 6y ago
  With respect to legacy code, it's interesting: I work a bit with ERP systems, and 10-year old legacy code from them is often significantly slower than the 25/30-year old legacy code in a prior ERP version from the same vendor. I think it shows that when developers are forced to work within tighter operating limits, they figure it out.
  - xellisx 6y ago
    Yeah, it a shame people say screw doing slightly more work to make a system as efficient as possible. Even some stuff like using $i++ vs ++$i. While, it only shaves one op code per pass, but it doesn't cost any time to type it out. Also people underestimate SQL indexes.
    - ineedasername 6y ago
      Indexes are actually one of the reasons the old code ran faster. Or the equivalent for that database type: I forget what it was called, but it wasn't relational. It was some type of file-based system where a file could be like a normal table, but it could also have "segments", where each segment might have a one-many relationship with the primary segment. Or you might "join" one file to sub-segment of another file, never going through the primary segment. So that was a factor, but so was the fact that the entire subsystem was pretty much written in COBOL, though I would occasionally write small C programs to work around limitations. Even newer versions of the ERP had a lot of the old COBOL still in it, just with a shinier new interface, but they were gradually replacing that code with (I think) Java. Probably because of the ability to keep finding & retaining COBOL talent, along with the need to make the product more readily interfaced via the web rather than a custom presentation layer from the vendor. (which was a green-screen terminal based interface, and significantly faster than any interface you'd see today. And with modern terminal emulators you weren't limited to green, you could choose any color! )
Narishma 6y ago
Dev tools themselves are often super bloated and slow, requiring tons of memory and storage, so maybe we should start with those.

awinter-py 6y ago

you may be right for consumer-facing functions where adding more boxes is cheaper at small size but slow internal tools are a direct tax on developer productivity this is an area where faster / smaller software does make a difference

smabie 6y ago

Most of the software that I use I would consider to be unacceptably slow on my top of the line workstation: emacs, webbrowsers, intellij; the list goes on and on. Something needs to be done, and fast. Pretty much everyone I know regularly complains about how slow and crappy the software they use is, especially my non-technical friends. We need to start thinking about performance as a necessary and basic feature, not some nice to have that can be worked on later. A new program needs to designed from the ground up to be fast, from the language choice to the data structures. And I think this shift is being made, except in web development circles. Most new and upcoming languages list performance as a basic feature: Rust, Julia, Nim, Zig, etc. Also, native compilation is often listed as a feature, as there's been a huge backlash against the vm cargo cult on the late 90s and 2000s.

throwaway_pdp09 6y ago
What's your problem with your emacs? Mine runs pretty snappy. Sometimes you get a runaway process in it which may be a problem but if you have problems every time, something else is wrong. As for browsers shrug, turn off JS and add a blocklist and it'll run an order of magnitude faster.
- rjsw 6y ago
  I didn't even feel that emacs was slow when I was running it on a 25MHz 386DX. The only real change between then and now is that I'm using a TrueType font with it.
- smabie 6y ago
  > What's your problem with your emacs? Mostly, company-mode lags when given a large autocomplete list. Also, large CSV files take a while to load.
  - throwaway_pdp09 6y ago
    First I've heard of company-mode, thanks for that. A DDG search gives https://company-mode.github.io/ https://company-mode.github.io/ as its first result, on their it refers you to its issue tracker - perhaps let them know if you haven't already? Large CSVs, Perhaps use LFV (large file viewer) if you want a read-only look. Otherwise I just loaded a 26MB binary file in less than a second. I created a 2.46 Gigabyte (not MB) CSV, opened it in a new emacs, took less that 15 seconds (fundamental mode). I think your problem lies elsewhere - it may be an unnecessary mode being invoked. How did the browser run when you turned off JS, a whole lot faster I imagine?