Most games render frames of a 3D world in less than 17ms, but most websites take 3-7 seconds to load because of all the ads and bloat, and things shift around on you for another 20 seconds after that, so when you go to tap a link you accidentally tap an ad that finally loaded under your finger. If you optimize those websites, they run super fast though, but it's quite a pain to do with the dependency bloat in modern tech stacks...

(note: games lag as well when you drag in a million dependencies you don't need)

The thing is, most sites and web apps try to solve a user problem, and if you are the only company in town that solves that problem, then performance barely matters - what matters is solving the problem. The users will put up with some pain because the problem is even more painful.

With games, it's all about the experience of interacting with the software - so performance is (hopefully, depending on your team and budget) amazing.

That, and... performance tuning is hard work, and I think most people don't know much about it. It's a fractal rabbit hole. Cache misses, garbage collection, streaming, object pooling, dealing with stale pointers, etc. Even I have a ton to learn, and no matter how much I learn, I probably still will have a lot more to learn. It's easier for many teams to hand wave it I guess as long as they aren't losing too many customers because of it.

Massive slabs of wood pulp had to be printed and shipped to all to the stores that stocked them, at huge cost, just so you could manhandle one of them home.

And the content was mostly physical bloat.

That's the modern web. Except that you don't just get the ads, you get some of the machinery that serves them - at you, specifically, based on your browsing profile, which is used to decide which ads you see.

I always refuse all cookies. When I forget to do that for some reason it's obvious just how much slower the experience gets.

Harsh but true.

Most (many?) games take minutes to load. Perf is nice once they're loaded (assuming you've got sufficient hardware), but loading is a drag. Modern load times are worse than all the fiddling it took to get NES games to start.

What are you loading them off? HDD? The only time I experienced a load time longer than a minute for any game was on a PS2 game that was scratched to high hell. It's possible that I'm simply interested in games that don't have long load times but I've played enough of modern AAA on console and PC to never have experienced this first hand.

After initial startup though, it depends a lot on the game itself how much loading you will wait for. I think SPAs are sort of the equivalent of zero-loading-screen games in some ways: both are trying to eliminate that loading pause.

Some awesome games were small. Other used a full 1.44" FDD. Some used 4 FDDs. Then the same happened with CDs. Finally only one CD needed. But there's space left over so later games made full use of it and soon there were games that needed 2 or more CDs. Lots of loading even going from one place to another. Decisions like "do I really want to go there now, I'll have to put in CD3 again". Or you bought the bigger HDD for much more $$$ and could install all 6 CDs onto that instead.

Can't run "Apache Longbow", need more RAM. But I can either buy the RAM or the game with the money I have. Damn!

What's been a blessing for me is not having the time to actually keep up with any of this time wise. Not enough time to really warrant spending money on new games and new hardware. Now I play games that are years and years old, I can get for cheap on GOG and that run fine on Intel Integrated graphics chips. Coincidentally those games usually load just fine in almost no time on modern SSDs as well and since I can't crank up the graphics full throttle, loading all that stuff into memory is relatively fast too etc.

Just take the example before, if twitter were server-side rendered, it would likely load in basically a blink of an eye.

The problem is code, which will later do more network calls which again have to be waited on, this is multiple round trips. Also, the fault lies probably a bit on web tech as well, html+css is just a terrible abstraction, layouting not being properly solved.

My Internet connection saturates my PLC at 10MiB/s, my ping is under the 15ms, and Twitter still takes ~2.4s to load and render a random tweet.

Twitter wants you to download their app and sign up so they intentionally neutered their web experience. It would probably require 0.1% of their 7500 employees to spend 3 months to fix it entirely, but it's business that drives the bad tech, not the developers

I build internal apps that load collaborative an entire app with MBSE capabilities that have a time to interactivity of < 10s. Google docs takes like 7s to spin up a new doc and interact with it. I can promise you Twitter could reduce rendering some stylish HTML/CSS and a 280 character tweet to a single round trip and see maximum 0.5s browser parse & paint if they wanted to

[0] https://dev.epicgames.com/community/learning/tutorials/ry2D/...

I don't think this is a fair comment. Theres an enormous tradeoff to make when compressing game assets, and uncompressed game assets are _absolutely enormous_. My current project has about 30 people at the moment. The game content is ~50GB, the client itself is ~4GB but the source substance files/fbx files/photogrammetry assets are tipping on 500GB. We're a _small_ AAA game. My previous project was closer to 500GB for the game content, and the source assets were multiple TB.

Tools like Oodle are third party licenses that need to be considered. Most games are compressing but switching to better compression methods can make the differences shown. Theres still huge tradeoffs to be made though. Most GPU formats for consoles require platform specific texture formats, and some of them don't compress well (hello dxt). You might have to trade a 20% file size reduction for a 30 second increase load time. Is that worth it? Maybe.

Either way, it's not just "dumb Devs". We care, we work hard on this.

Edit: never mind. Saw this being discussed elsewhere in this thread.

I may have come too rough in my comments and lost the original intent. I was hoping to defend that devs _already have_ access to good compression tools and that they already use them, and 70gb games are that big after compression is applied. That's where my assumption started.

I understand well that there are custom formats for different platforms, and that the whole reason these tools exist is not to squeeze an extra 10% smaller files, but to get fast load times while maintaining small file sizes.

> My previous project was 500gb

That wouldn't surprise me to be honest. It makes perfect sense.

And there are YT videos that call developers out for mushy textures on every new game release.

At the time it was like… wait I just bought this fancy CD-ROM… why do I need to install 30 or 40 whole megabytes to disk to play it?

At that time it was pretty common to actually install all the game files to disk (drives were slow… I think it was 4x read speed) and then the music was encoded in the cd as additional tracks of plain CD audio.

The earliest cdroms that I remember were 1x drives - so it took an hour to read that 700MB. Obviously drive speeds increased tremendously over the lifespan of cdrom (did it reach 48x?), but compared to the earliest generation it is about the same.

Sometimes you got a really bad installer, and it could take a pretty grueling 2+ hours. Some companies chose to optimize for space (thus cost..) rather than user experience.

As space got more plentiful it would sometimes be easier to copy the disk and remount it and then install.

This is why some people love game streaming. Esp true if you only play a game once in a while.

Most 'performance tuning' out there is eliminating quadratic functions and putting stuff into simple dictionary caches. This should be easily teachable to any competent developer.

The problem isn't 'hard work', it's nobody cares about this.

Getting measurements that help you identify where the bottlenecks really are can take time. Often these have to be retrofitted into existing complex system, when the project is already underway.

Sometimes the only way forward is replacing the current way of doing things with a more efficient way of doing things. This requires understanding the current way well (it can be the result of many teams working together for months) as well as coming up with a new design. Both of these things take time.

Finally, there's bug hunting, where you get into rabbit holes. "There's a slowdown when we're on this particular step. You investigate for days, until you realize that the slowdown only happens when the user mouse is near a section of the screen. It turns out that there's a non-visible UI element that should be inactive but it isn't because it is a custom element instead of one provided by the UI library, and it is attempting to render a special effect but finds no graphical context, so it request for a new context once per frame." And one week of dev time has passed.

In most games this doesn't matter, but occasionally you have a frame time target and you need to take extra steps like that. Those extra steps can be hard work when they come up!

Even when you use SIMD intrinsics?

For example: https://en.wikipedia.org/wiki/Intel_SHA_extensions

A repo I just found illustrating those instructions' usage: https://github.com/noloader/SHA-Intrinsics

Source is the measurements here: https://uops.info/table.html

That'd make SHA256RNDS2 even faster because of the throughput numbers.

I'm curious, what's the faster algorithm for hashing you use? I don't want to waste time on intrinsics and inflict complexity on my colleagues if there are alternatives I can use!

For example, I need to reorder a matrix and change my access pattern to it to extract more performance and reduce cache trashing by exploiting cache prefetch dynamics of a CPU.

I need to test this with every CPU generation and test whether it works as expected performance-wise.

To achieve this, I need to rewrite half of the said software.

The reason I’m not doing this is it’s still way faster than other software I’ve seen in that category, and extreme performance tuning can hurt flexibility of the code down the road.

That does happen, but some of the more severe performance issues I've seen are memory related. Every byte allocated has to be freed. If you lower the memory profile of your function then you reduce the overhead of running the code significantly.

I recall a web service that ground to a halt and would sit at 100% CPU, after I put it in a profiler 97% of the cycles were in the garbage collector. Dig a little deeper and I found that the caching library used was cloning the data before sending it back. Ahh, junior devs.

I rewrote a library with the same interface that did not clone the data, this was safe as the original data wasn't being changed, 15x speedup from 10 req/s to 150 req/s.

Then I dug deeper and changed which data was getting cached. Cache post-render and post-compression instead of the pre-render database calls. 150x speedup from the original or 10x from the previous point. The system went from being able to serve 10 requests/s to 1500 req/s. This change also was safer since nobody is going to ever try to alter compressed data, no such guarantees from the cached database calls.

A sibling poster also comments that dictionaries are too slow. They might be in a game setting, but definitely not in a Java backend service.

Most (non FAANG) sites are a mess because they're made by inexperienced developers turning everything they touch into a tangled slow mess.

The process goes like this:

- Devs ditch the legacy (often monolithic) code

- They start creating microservices fron scratch

- They don't see the need to optimize or even make readable code. It's a clean slate! the project is small, the new code is just whatever they write.

- They do that with the idea that the legacy code is "bad" and the new code is "good"

- Requirements either scale or downright change

- To the code made before, they add a "tiny" special case and patch here and there. After all, the code is "good"

Repeat

Now you have a new messy project. The dev will either quit or work in a new project. The next dev will do the same. And the new team will probably push for another replacement from scratch, so they can feel that they re creating "good" code again

Now try to take some React developer that has been working for years in completely different abstraction level, and help him design more performant code base.

You really think all you will talk about are cache misses?

i also had a chat with a C++ dev that created a "Database"-class abstraction for our MongoDB instance and implemented methods to access each field of every documents separately - didn't care about side-effects, didn't know about ACID transactions and didn't care.

finding a good abstraction that allows for performance tuning later on is hard, no matter the language, and react devs should make use of good abstractions as well.

Also, the website teams is usually smaller, and have a 10th of the time to ship.

But it doesn't excuse everything, for sure. Most websites should be fast given how little they do.

We had Adobe Illustrator, XD was still in beta phases, and Sketch for macOS was showing signs of bloat and major performance hangups in any considerably realistic document. Affinity Designer was also coming into the scene with stellar performance, but had a high learning curve and wasn't well suited for interactive prototyping.

Figma swooped in and solved 3 problems:

1. Availability in the browser on any platform, where native apps can't reach (and thus 10x easier sharing of documents). 2. Incredible performance on first release through their WebGL renderer, rivaling all of the native apps listed above. 3. Stayed flexible, and yet, barebones enough to get at least 80% of a designer's needs covered initially.

Performance (and stability) were primarily what won me over to it, and I'd argue probably the same for many who switched over.

Why don’t browsers mask out events during render of page regions or note their time and bounding boxes so click events reach the correct element?

Steps to reproduce this annoyance:

- visit Twitter mobile site: mobile.twitter.com in Safari on a slow iPhone (eg iPhone 6 stuck on iOS 12.X). - scroll and view tweets for a while soaking up memory. - visit a tweet - press tweet share icon - popup menu takes forever to render fully to include the Cancel button. - clicking Bookmark tweet menu item will trigger item after that, Copy Link to Tweet, when it finally loads and moves that menu item under your finger.

Well now, "most games" will take longer than 3-7 seconds to load. That's fair - they're doing a lot more than websites!

Most websites also render frames in less than 17ms.

The problem with remarks like this is that if this was really your experience of using the web you'd have installed an ad blocker years ago, and you wouldn't make that argument now. Consequently either it's easily dismiasable as hyperbole or you're a masochist who enjoys terrible websites.

There are bad websites. It isn't "most websites" though. Just like some games drop frames horribly, but not "most games".

But fair enough, it might not actually be most websites, but enough to not be a rare experience either.

- 131 network calls

- 280 kilobytes of data received

- 4500ms total network time

Thankfully, the vast majority of other websites aren't nearly this bad, but we're trending towards twitter as an industry, not away from it.

I try to write API calls that provide broadband utility and return lightning fast by always making sure my critical path gets a fair shake for optimization, but I know there exist calls out there in react land that take my 220ms response and spend an extra 7 seconds transforming it to populate a (paginated) table on the UI.

And GP's point still stands. 17ms vs the typical 2s minimum a site takes to load is massive given the differences in what is demanded. Games actively got faster despite being more intense, websites active got slower despite relatively similar output.

Webdev's performance is shocklingly bad relative to most other subfields.

You too ignore this.

Plenty of websites scroll at 60fps or 120fps just fine (and those that don’t definitely deserve to be criticised).

How many console games can load from scratch in only a few seconds?

It's no longer a universal truth that a adblocker will save you memory or CPU, ad-blockers contribute greatly to the per-tab memory cost. They also slow down page rendering greatly.

But, hey, the web is an unusable mess without them so we all use one and it's considered the cost of doing business.

This comparison I made at https://legiblenews.com/speed that got upvoted here a while back shows just that—most news websites care about ads first before their users speed experience. Only Legible News, USA Today, and Financial Times have a reasonable speed score, which is kind of depressing.

I'm a game developer (and player) and I strongly disagree. What game can even do P95 144FPS on affordable hardware? On lowest graphics, with populated lobbies (there also can't be a that ONE map where this all goes to shit). And are we talking about AAA games or not? Because non-AAA means a minecraft knockoff cannot meet 60FPS.

It could be, if users would have more control over the graphics settings of the games that they want to play and they were allowed to scale back further to accommodate older hardware.

For example, the Unity engine by default has a setting to allow downscaling the texture resolution that the game will use 2X, 4X and 8X, yet many games out there actually disable that. Same for some options menus not having framerate limits, dynamic render resolutions (though most engines support that functionality in one way or the other), particle density/soft particle options, options to disable SSAO/HBAO or other post processing like that, as well as enabling/disabling tessellation.

The end result is that many games that could run passably on integrated graphics or hardware from a few generations ago (e.g. GTX 650 Ti) instead struggle greatly, because the people behind the game either didn't care or didn't want to allow it to ever look "bad" in their pursuit of mostly consistent graphical quality (and thus how the game will look in the videos/screenshots out there).

The only real exception to this are e-sports titles, something like CS:GO is optimized really well for performing across a variety of hardware, while also giving the user the controls over how the game will look (and run). Games like DOOM are also a good example, but they're generally the exception, because most don't care about such technical excellence (though it's useful when you try porting the game to something like Nintendo Switch).

Most other games don't give you that ability, just because they try to always do more stuff, which isn't that different from Wirth's law (software gets slower as hardware gets faster). Of course, this is also prevalent in indie titles, many of which don't even have proper LOD setups, because engines like Unity don't automatically generate LOD models and something like Godot 3 didn't even have any sort of LOD functionality out of the box.

Engines like Unreal might make this better with Nanite, except that most people will use it for shoving more details into the games (bloating install sizes a bit), instead of as a really good LOD solution. That said, Godot 4 is also headed in the right direction and even for Godot 3 there are plugins (even though it's just like Unity, where you still need to make the models yourself), for which I actually ported the LOD plugin from GDScript to C#: https://blog.kronis.dev/articles/porting-the-godot-lod-plugi...

If the game is popular then someone usually comes along with a DLL that allows you to tweak at least some of the settings that weren't exposed.

While it's not an exhaustive list, you can open any of those features and sort the table by whether the game supports the functionality itself, needs some sort of a config/tool fix/hack or does not support in any known way.

(the list is so long that you might have to view it with 500 items per page and even then jump through multiple pages, I wonder whether the dataset can have aggregate queries against it done)

I know what you want to say (and I agree), but... website rendering depends on the network mostly, 16ms latency is already the top 0.5% of fiber users and you have to add that on top of every new connection... GPU rendering happens on a bus that is thousands of times faster, and it needs to cover a minuscule distance. You can't really compare the two.

Differences in order of magnitude.

That said, websites and even web apps really should be faster.

No they don't. Your compiler will eliminate dead code.

Parent did write that "game lags as well when you drag in a million dependencies".

That is hard for me to interpret like you did.

This is why I love working in fintech. The engineering is paramount. Customers will not accept slow or buggy software.

I get to solve hard problems, and really build systems from the ground up. My managers understand that it is better to push back a deadline than to ship something that isn't up to standard.

Better than adtech, anyway. Or nukes. Lots of things, really. (I would have said weapons, last year.)

The only really defensible tech activity these days is things to help get off carbon-emitting processes. Making factories to make electrolysers. Making wind turbines better. Adapting airliners to carry liquid hydrogen in underwing nacelles. Making robots to put up solar fences on farms and pastures. Banking energy for nighttime without lithium. Making ammonia on tropical solar farms for export to high latitudes.

It's even money whether we can get it done before civilization collapses. I guess we will need plenty of liquidity...

Other problems are also worthwhile to solve. I agree that zero-sum HFT and negative-sum adtech and arms races are not the most prominent ones.

10% of all deaths each year are due to air pollution. There's pretty much no place on earth where unfiltered rainwater is still safe to drink. Ocean acidification is accelerating and killing off the organisms that are both the biggest producers of oxygen and the biggest sequesterers of carbon.

Rainwater harvesting risks seem to be primarily due to birds pooping on your roof and other fecal contamination, and they can be adequately mitigated by boiling or chemical sterilization: https://www.nature.com/articles/s41545-019-0030-5.

Climate change very likely would collapse your civilization, given enough time, but that isn't what is happening now.

Alphabet's yearly revenue is US$258 billion, some of which is earned from things like Google Play, Google Cloud, and Google Workspace, and some of which has been spent on things like Makani, Verily Life Sciences, DeepMind, and Google Fiber. Meta's revenue is US$118 billion.

https://www.globaldata.com/data-insights/internet-services-t... says, "Google earned nearly 81% of its total revenues in 2021 from advertisements," and it's talking about that US$258B number, not some smaller number that excludes other Alphabet companies.

We can maybe estimate the whole adtech spend, generously, at US$400 billion per year [edited: was US$300 billion]: most of Alphabet, all of Meta, plus a handful of smaller fish. (I say this is "generous" because it's counting all the effort that goes into running Google Search, YouTube, Instagram, and Android development as "adtech", because it's monetized through ads, even though most of the people working on those projects are not directly concerned with ads; if you omit that, you might size adtech at only US$50 billion.) And maybe US$200 billion per year goes into the renewables transition. I'm not convinced that doubling that to US$400 billion per year would guarantee a win, particularly when the humans are going around bombing each other's power plants, snarling up power plant construction and energy-efficient housing in red tape, and publishing disinformation that "debunks" global warming.

These are of course very rough estimates, but how would you estimate these numbers?

As far as I know, there aren't any invaders the humans are fighting; they're only fighting other humans, plus the occasional rogue elephant.

Invasion is an activity, not an identity. Those so engaged could stop anytime. Many will.

Apparently it has not had that effect in Romania, yet. But they are by report still happy with their Canadian CANDU reactors.

People program computers to exchange messages furiously, to no external effect besides power consumed. Then they go buy yachts. It's all perfectly legal, of course.

As a society, we like to reward people who do things that are useful: feed, house, clothe, warm, transport, educate, protect, medicate, lately amuse people, and get money that may be exchanged for those services, or yachts.

HFT traders provide none of those, nor anything comparable, but get yachts anyway.

Ah, so you lack a basic understanding of how the stock market works, but think you're qualified to make very strong statements about it.

Btw, you need to be careful, because people might still race to be the last (or first) to contribute to a batch.

They'd race to be the first, if tied prices within a batch are resolved in favour of the earlier bird. Otherwise, they would race to be the last, so they have the most information available when deciding on their price (and so that they can change their mind until the last nano-second.)

Granted traders can play other games, but their primary benefit to others is significant

You must be lucky, not everywhere in the sector that’d be remotely close to true unfortunately…

Stock traders forced a lot of advances onto software. Random examples of high-perf stuff from that space include the new garbage collector in the JVM with a minimal pause time and LMAX Disruptor. Multi-threaded GUIs are relatively common in that space as well, to ensure that one hung control or window won't stop anything else.

The prototypical nerd would happily work on building a nuke capable of destroying a continent if that entailed letting him work on “hard problems”.

Missiles don't really need GC or RAII. They have their own special resource clean up.

But I've also seen productionized jupyter notebooks written by just out of school data scientists and 1000 lines long SQL queries that encoded important business logic and weren't version controlled.

It is impressive that they can draw so much stuff so fast, but there are actually very few objects on the screen that the user can directly interact with.

A specific example: in a DAW, you might have tens or even hundreds of thousands of MIDI notes on the screen. These look like (typically) little rectangles which are precisely the short of thing that games can draw at unbelievable speed. But in a DAW (and most design / creation applications), every single one of them is potentially the site of user interaction with some backend model object.

All those complex surfaces you see in contemporary games? Very nice. But the user cannot point at an arbitrary part of a rock wall and say "move this over a bit and make it bigger".

Consequently, the entire way that you design and implement the GUI is different, and the lessons learned in one domain do not map very easily to the other.

As long as it doesn't cause a glitch in playback, it's acceptable for your DAW to delay 10 milliseconds to figure out which note you clicked on. That's about 100 million instructions on one core of the obsolete laptop I'm typing this on. As you obviously know, that's plenty of time to literally iterate over your hundreds of thousands of little rectangles one by one, in a single thread, testing each one to see if it includes the click position.

But (again, as you obviously know) you don't have to do that; for example, you can divide the screen into 32×32 tiles, maybe 8192 of them, and store an array of click targets for each tile, maybe up to 2048 of them, but on average maybe 64 of them, sorted by z-index. If a click target overlaps more than one tile, you just store it in more than one tile. When you have a click, you bit-shift the mouse coordinates and combine them to index the tile array, then iterate over the click targets in the array until you find a hit. This is thousands of times faster than the stupid approach and we haven't even gotten to quadtrees.

A different stupid approach is to assign each clickable object a unique z-coordinate and just index into the z-buffer to instantly find out what the person clicked. This requires at least a 24-bit-deep z-buffer if you have potentially hundreds of thousands of MIDI notes. But that's fine these days, and it's been fine for 25 years if you were rendering the display in software.

It's not like games don't have complex UIs either, where each button or field has a lot of logic to them. Many games have very simple UIs, but others get more complex than many complex web apps. Some are even multiplayer, and the server code... it's nuts how much work goes into this. The number of updates you send each second to keep players in a game in sync compared to what is needed to keep a chat app in sync is really impressive to me.

From a technical point of view, games are really cool!

It's not like in the olden days where you would blit this stuff out to the screen using specialized routines that scream along as fast as the CPU will let you. Now, everything is dynamic and multipurpose and configured using properties on the object... engines like Unity get away with C# and way too much runtime reflection because it's convenient in the editor. Developers like it, it's less difficult than writing specialized routines.

> > With a modern data driven or ECS architecture, you actually can do that.

At some point people forgot that there are synonyms and different ways to phrase “actually”.

The Red Faction series, building games like Minecraft and 7 Days to Die, and games like Factorio are some pretty obvious examples where you're completely and utterly wrong, so I'm not really sure why I should trust anything you said in the rest of your comment.

Games (generally speaking) do not involve allowing the user to interact in arbitrary user-defined ways with every object represented on the screen. The interactions that do happen are part of the physics engine not the "user clicked that and dragged it to the left" engine.

Considering how many objects and interactions Factorio tracks and at the same time lets you move around, inspect any of those things etc.

A typical app on the other hand does a CRUD operation every once in a blue moon.

Ah yes, and which apps actually allow you interaction in arbitrary user defined ways?

By contrast, most design/creation applications give you the ability to point with the mouse (or touchpad or whatever) at some object on the screen and then move it (sometimes along 3 axes). The speed of the motion, the axial extents and the destination come (at least initially) from you. This is true of drawing applications, design applications, DAWs and lots more.

You can quite literally point at an arbitrary part of a rock wall and move it over a bit then make it bigger depending on the engine you're using. It's why Unreal Engine has got a foothold in TV production.

In some games, you can.

They routinely do have hundreds, or thousands, of interactive things. Especially things like RTS games. But also, even if you look at turn-based strategy games, which have a much more application-like interface. Every hexagon, terrain feature, and unit is interactive, along with a full application-like menu, statusbar, and UI system.

I think most of all, it isn't sufficiently visible. Most development is done on high powered hardware that makes slow code very difficult to distinguish from fast code, even though you can often get 10x performance improvements without sacrificing readability or development effort.

Individually it's just a millisecond wasted here and there, but all these small inefficiencies add up across the execution path.

Here's a fun benchmark to illustrate how incomplete beliefs like "compilers are smart enough to magically make this not matter" can be:

https://memex.marginalia.nu//junk/DedupTest.gmi

It's a 50x difference between the common idiomatic approach and the somewhat optimized greybeard solution, with a wide spectrum of both readability and performance in-between.

If you put zero thought toward this, your modern code will make your modern computer run as though it was a computer from the late '90s.

Honestly, what I want is for more developers to test and optimize their software for low-power machines. Say, a cheap netbook for example (like a Chromebook). I've heard that if you do that, you will be faster than basically every other piece of software on the system. And that speed will persist (multiply, even) on any more-powerful computer.

I've heard of one person who does that for their Quake-engine game/implementation (don't remember which). They get thousands of frames per second on a modern machine. I am guilty of not doing that myself, though. Might pick up a cheap netbook from eBay for around $30.

Because the software on them predates the explosion of GCs, JITs, and hundreds of layers of abstractions & dependencies. All those techniques that improve developer iteration & velocity came at the cost of runtime performance.

Also, improving developer iteration and velocity is possible without doing this.

Bloat usually happens at the top 2 layers (actual program code and its dependencies), not from the runtime/OS/hardware.

> Hell, a hot loop in Java can be as fast as C code

Only if the Java code in question is written like C code and not like Java code. Which is sometimes possible, yes, but very very rare, and almost never done.

> and it has support for vector instructions as well if you want to write even faster (and platform-independent) code than you could with only C.

Absolutely nonsense. C compilers are more than capable of cpu-specific vectorization, too. CPU detection at runtime is ancient technology and perfectly compatible with AOT languages. And since offline compilers have the benefit of getting to spend all the time in the world on it, regularly and consistently have much better auto vectorization outputs.

JITs are normally under such a time crunch that it's common for their initial output to be quite mediocre, hence why you end up with multi-level JITs. Which then take even longer before the code stops being slow. Great for benchmarks, but pretty shit in the real world for general app performance.

Now you can sometimes have your cake and eat it too here, such as what Google is doing with cloud profiles on Android to basically run the JIT ahead of time. But that is very far from the norm for JIT'd things.

And it's not like the JIT actually provides any advantage here anyway. There's no shortage of similarly high level SIMD libraries for the AOT-world.

My hunch is that the extreme indirection makes mince out of data locality during traversal, since TreeSet is backed by a red black tree, so conversion to list is O(n) cache misses, whereas the sorting algorithms are reasonably well behaved from a cache perspective (Java uses a dual pivot quicksort for primitives and TimSort for objects IIRC).

  > Most development is done on high powered hardware that makes slow code very difficult to distinguish from fast code, even though you can often get 10x performance improvements without sacrificing readability or development effort.

I saw a project that had a very clear N+1 problem in its database queries and yet nobody seemed to care, because they liked doing nested service calls, instead of writing more complicated SQL queries for fetching the data (or even using views, to abstract the complexity away from the app) and the performance was "good enough".

Then end result was that an application page that should have taken less than 1 second to load now took around 7-8 because of hundreds if not thousands of DB calls to populate a few tables. Because it was a mostly internal application, that was deemed good enough. Only when those times hit around 20-30 seconds, I was called in to help.

At that point rewriting dozens of related service calls was no longer viable (in the time frame that a fix was expected in), so I could "fix" the problem with in memory caching because about 70% of the DB calls requested the very same data, just in different nested loop iterations. Of course, this fix was subjectively bad, given the cache invalidation problems that it brought (or at least would bring in the future if the data would ever change during cache lifetime).

What's even more "fun" was the fact that the DB wasn't usable through a remote connection (say, using a VPN during COVID) because of all the calls - imagine waiting for a 1000 DB calls to complete sequentially, with the full network round trip between those. And of course, launching a local database wasn't in the plans, so me undertaking that initiative also needed days of work (versus something more convenient like MySQL/MariaDB/PostgreSQL being used, which would have made it a job for a few hours, no more; as opposed to the "enterprise" database).

In my eyes, it's all about caring about software development: either you do, or you don't. Sometimes you're paid to care, other times everyone assumes that things are "good enough" without paying attention to performance, testing, readability, documentation, discoverability etc. I'm pretty sure that as long as you're allowed to ship mediocre software, exactly that will be done.

Yes, that's the difference. I'm lucky enough to work mostly with colleagues that share a certain level of craftsmanship about the software we ship. We all care about the quality of the product, although we may not always agree on what an ideal solution should look like.

(If you go this route, you've got to be careful what's been trimmeed, mind, if you want to use it for general purposes - mine doesn't have WSL and seems to have damaged printing support, which is obviously suboptimal depending on your needs.)

If I could go back in time and make one change to the history of computing, I'd add code to every consumer-facing GUI OS that would kill-dash-nine any application blocking UI thread for more than say 200ms. And somehow make it illegal to override for any consumer software, or if I were God make it so any developer trying to override it to let their software be slow gets a brain aneurysm rendering them (even more) incapable of writing software and has to find work digging ditches.

My old company used a proprietary VPN software (Appgate SPD) that used an electron front end - why? Well the front end could be reused on Windows, Linux and MacOS. Fair enough but it was very bloated and lacked features. Compound that to half a dozen electron apps and suddenly my laptop battery dies in half the time.

We can't guarantee or mandate that every project will be written in Rust, multiple times for every platform using their native APIs - so it's on the tool makers to bridge that gap.

Electron shows that we need a robust, efficient, cross-platform, cross-language GUI API.

Would be nice to be able to use Go, Rust, Python, JavaScript or whatever and interact with an GUI interpreter that translates a familiar API to native widgets.

The truth is, Electron is easy to use, quick to hire and cheap to build on, that makes it the best choice for many companies, even when the user might (highly-likely) hate it.

Telling users what they ought to want is not a very good idea.

Not in the sense that every project needs awesome performance. But in the sense that requirements should not what performance goals are required.

So you should note down target throughput and latency for different scenarios in your requirements.

That can be as simple as saying that any user interaction should give feedback within one second. (Be that either doing what the user requested within that one second, or giving some indication that the program is working on it.)

The way that GP comment was written though made it sound like good performance should be part of the requirements for all software, which is what I disagree with.

On the other hand, lots of software is custom-built for a specific end-user. E.g. an organization's internal tooling. There, you can often sacrifice a lot of things for it to be done faster, depending on the use case. In that case, I consider the user to be the "organization" or specific people/teams within that organization.

That is to say -- not cheap.

This is sheer stupidity: a more complicated, less efficient solution to a simple problem.

They presumably wanted to recursively enumerate all the files under the Sound recordings directory?

(In any case, for the application programmer the difference between recursive enumeration of files vs only what directly in a specific directly is likely only one flag or so.)

That said I did work at a major media company and the performance sucked (in the help section) and I said I want to improve it and the PM said "nobody cares" but I think she meant the business didn't care. So there is one anecdote supporting your claim!

They are all much more powerful than Apple notes but they are so slow by the time they are ready for my input I have forgotten what I was trying to note down.

Visual Studio and Adobe Creative Suite are examples of the two most egregious offenders. They're both awfully slow and Creative Suite is extremely buggy as well. Visual Studio is nearly 30 years old, and Photoshop is even older. That's a lot of features to have to carry forward over the years.

It would be neat if during setup, they tried to figure out what your goals were as a user and turned stuff off you didn't need. My pet peeve about Visual Studio is whenever I upgrade to a new version, my default setting overrides are not carried over.

Then on top of that, companies are making choices like “we could optimize X and Y, but that would take too much dev time. Let’s just (compromise somewhere/bump up the requirements)”

Also, it's about caring enough to actually stop using it. Have you ever changed software to a competitor with better performance? I don't know if I have..

We’re stuck and getting stucker.