3 ms·
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 sh
by 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 agoIndexes 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! )