I just started getting back into gaming and I'm seeing shit like this all the time. It's amazing that stuff like this is so common while the Quake fast inverse square root algo is so well known.

How is it that these companies spend millions of dollars to develop games and yet modders are making patches in a few hours fixing bugs that never get merged. Not some indie game, but AAA rated games!

I think you're right, it's on both management and the programmers. Management only knows how to rush but not what to rush. The programmers fall for the trap (afraid to push back) and never pull up a profiler. Maybe over worked and over stressed but those problems never get solved if no one speaks up and everyone is quiet and buys into the rush for rushing's sake mentality.

It's amazing how many problems could be avoided by pulling up a profiler or analysis tool (like Valgrind).

It's amazing how many millions of dollars are lost because no one ever used a profiler or analysis tool.

I'll never understand how their love for money makes them waste so much of it.

> To me that's profound. It implies that not only was management not concerned about the start up time, but none of the developers of the project ever used a profiler.

Odds are that someone did notice it during profiling and filed a ticket with the relevant team to have it fixed, which was then set to low priority because implementing the latest batch of microtransactions was more important.

I feel like this is just a natural consequence of the metrics-driven development that is so prevalent in large businesses nowadays. Management has the numbers showing them how much money they make every time they add a new microtransaction, but they don't have numbers showing them how much money they're losing due to people getting tired of waiting 15 minutes for the game to load, so the latter is simply not acknowledged as a problem.

iirc this bug existed from release but didn't impact the game until years later after a sizable number of DLCs were added to the online mode, since the function only got slower with each one added. Not that it's fine that the bug stayed in that long, but you can see how it would be missed given that when they had actual programmers running profilers at development time it wouldn't have raised any red flags after completing in ten seconds or whatever.

> It disturbs me to think that this is the kind of world we live in. Where people lack such basic curiosity. The problem wasn't that optimization was hard, (optimization can be extremely hard) it was just because nobody gave a shit and nobody was even remotely curious about bad performance. They just accepted bad performance as if that's just the way the world is.

The problem is, you don't get rewarded for curiosity, for digging down into problem heaps, or for straying out of line. To the contrary, you'll often enough get punished for not fulfilling your quota.

> and anyone with an ounce of curiousity would be like, ".........wait a minute"

I see what you did there ;)

> Another datapoint that supports your argument is the Grand Theft Auto Online (GTAO) thing a few months ago.[0] GTAO took 5-15 minutes to start up. Like you click the icon and 5-15 minutes later you're in the main menu. Everyone was complaining about it for years.

I see this is a datapoint, but not for your argument. This thing sat in the code base didn't cause problems and didn't affect sales of the game pre or post GTAO launch.

This sounds a lot like selection bias. You want to enhance airplanes that flew and returned. Rather than those that didn't come back.

Let's say they did the opposite and focused on improving this over a feature or a level from GTA. What level or what feature that you liked could you remove to make way for investigating and fixing this issue? Because at the end of the day - time is zero-sum. Everything you do comes at the expense of everything you didn't.

Honestly the GTA5 downloader/updater itself has pretty bad configuration. I wrote a post about it on Reddit years ago along with how to fix it.

I don't know if it's still applicable or not because I haven't played it for ages, but just in case it is, here's the post: https://www.reddit.com/r/GTAV/comments/3ysv1d/pc_slow_rsc_au...

I think you're right. Early on I did HPC and scientific computing. No one talked about Big O. Maybe that's because a lot of people were scientists, but still, there was a lot of focus on performance. Really how people were optimized is with a profiler. You talk about the type of data being processed and how and looked for the right way to do things based on this and people didn't do the reductions and simplifications in Big O.

Those simplifications are harmful when you start thinking about parallel processing. There's things you might want to do that would look silly in serial process. O(2n) can be better than O(n) because you care about the actual functions. Let's say you have a loop and you do y[i] = f(x[i]) + g(x[i]). If f and g are heavy then you may want to split this out into two loops y[i] += f(x[i]) and y[i] += g(x[i]) since these are associative (so non-blocking).

Most of the work was really about I/O. Those were almost always the bottlenecks. Your Big O won't help there. You gotta write things with awareness about where in memory it is and what kind of memory is being used. All about how you break things apart, operate in parallel, and what you can run asynchronously.

Honestly, I think a big problem these days is that we still operate as if a computer has 1 CPU and only one location for memory.

What more harmful is probably not having a set of guilds / unions (that both work together, share the same collective bargains, but also compete for members) to cut a lot of the annoying for ALL sides involved interview process out.

Why do they ask about Big O? Because it works as a filter. That's how bad some of the candidates are.

What would I rather they do? Have a non-trivial but obviously business unrelated puzzle that happens to include design flaws and the interviewee is given enough time and latitude to 'fulfill the interface, but make this the best it can be'.

The splash screens usually "hide" various loading steps. In Excel it's often loading and initialization of various extensions, for example.

Maybe it's phoning home to verify the app, or whatever it is it does? Launch times for MS Word on my 11 year old Macbook Pro, approx time to the opening dialog:

First run since last reboot: 19 seconds

Second run: 2.5 seconds

Third run after sudo purge: 7 seconds

Maybe it's an artefact of where I live, but the verify step always takes ages. First run of anything after a reboot takes an outlandish amount of time. GUI stuff is bad; Unix-type subprocess-heavy stuff is even worse. Judging by watching the Xcode debugger try to attach to my own programs, when they are in this state, this is not obviously something the program itself is doing.

Are we talking about Word, or a text editor? They seem to be saying the latter, particularly given the comparison with vi. I consistently get about half a second to open TextEdit on an M1, and that seems to be due to the opening animation.

It does not. In fact, it crashes roughly every 4th or so startup.

I mean we're talking about a fucking text editor here. A second to load is a long time even if it was on an intel i3 from 10 years ago. Because... it is a text editor... Plugins and all the fancy stuff is nice, but those can be loaded asynchronously and do not need to prevent you from jumping into a blank document.

But the god damn program is over 2GB in size... like what the fuck... There's no reason for an app I open a few times a year and have zero plugins and ONLY does text editing should even be a gig.

Seriously, get some context before you act high and mighty.

I don't know how anyone can look at Word and think it is anything but the accumulation of bloat and tech debt piling up. With decades of "it's good enough" compounding and shifting the bar lower as time goes on.