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.
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.