I'm thinking a lot about this lately. I've spent most of the last month figuring out why game code I wrote in Lua for specific hardware, which was running along just fine for months, suddenly got much slower in certain situations. The answers mostly came down to "higher-resolution stereo audio files in the wrong format take WAY more cpu time than comparable-sounding files at a lower resolution in the system-appropriate format," (though the docs said the other format was fine, they were wrong!); and, in my naivete, I hadn't been properly removing unused processes in the background. So, even though I thought things weren't running in some cases, they were, and this was a problem when several scenes wound up layering on top of each other.
These were pretty big, "oh!!!" fixes, that mostly arose out of working in an unfamiliar environment. These can be understood, and are a major relief to solve.
But there's a bunch of little optimizations you can do in Lua that are... well, honestly, ridiculous. How should you insert a new entry in a table? Well, probably
table.insert(table_name, value)
...right? That's the language's provided method. Nope! Turns out it is often way faster to call
table_name[#table_name + 1] = value
which is like saying, "For the position that comes 1 after the length of the table (aka the last position, plus one) make it this new value!" Holy shit!
This happens all over the Lua built-in methods. Do not use table.unpack(table_name)
to get values out of a vector2! It's always better to manually assign values, like local x, y = table_name.x, table_name.y
. You should never use ipairs()
if you can help it; it's always better to get the length of the table and then do a simple for loop over the length. Like, WAY faster. I could go on, at great length! But despite having read most of the Lua Manual and its Programming in Lua companion book, I had learned a lot of bad code practices and used them all over my codebase, losing milliseconds of time per frame, and fighting some pretty bad performance hiccups.
... speaking of which! I just paused and spent over two hours configuring syntax highlighting so I could illustrate this! LOL the web is so fucked
Anyway, I read these posts by Nikita, It is fast or it is wrong and Performance first, and find myself nodding. There's definitely a phase in coding where you just literally have to make it work at all. That's fine, if you have no idea how to do it, of course you can't worry too much about whether you're also doing it "the best way". But then... in my limited experience, you aren't done with the feature unless it also runs as well as you can reasonably make it. And that's hard! It takes extra work. But... so much software is so bad. It's really driving me nuts lately. Particularly when massive-scale operations like Apple, Slack, Dropbox, et al, are just dropping the ball straight through the floor.
Particularly:
Browsers? Same story. HTML is a pretty inefficient way to put pixels on a screen. A computer that might render millions of polygons a frame could easily struggle to scroll a web page. Same as with Advent of code solutions, it doesn’t really depend on how powerful your computer is. And even a highly optimized web code based on Canvas and WebAssembly (Figma) makes my Macbook fans spin while running native Sketch in complete silence.
There’re just limits on how far this wrong solution can go. Electron text editors can’t resize their own window in real-time and drop frames while you just move your cursor around. Slack would be as slow and memory-hungry on iMac Pro as it would be on a 12” Macbook.
The whole solution, the “web stack”, is wrong. The same thing could be done faster and more efficient easily—there is just so much wasted potential. Time to admit that and start over. There are fast text editors and chat programs around, very well within capabilities of even the least powerful netbooks.
I reckon all I can do is try my best to have the things I ship be as fast as I can manage! And then somebody else can complain about me in their posts.