3 ms·

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

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! )

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! )