Why modern software is slow
randomascii.wordpress.com
randomascii.wordpress.com
For commercial airplanes it may be safety first, ticket price second (passenger capacity, fuel efficiency) and speed third. For most software, functionality, signing up for a subscription, platform availability etc are usually prioritized higher than response times and keyboard shortcuts.
Game devs worry a lot about latency and frame rates and professional software care a lot about keyboard shortcuts. This proves (anecdotally) that performance isn't unacheivable at all, but rather deprioritized. Nobody wants slow apps but it's just that developer velocity, metrics, ads etc etc are higher priorities, and that comes with a cpu and memory cost that the vendor doesn't care about.
That is to say -- not cheap.
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.
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.
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.
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.
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.
Granted traders can play other games, but their primary benefit to others is significant
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.)
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.
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.
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!
> > 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”.
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.
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.
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.
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.
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..
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.
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.
[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.
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.
Edit: never mind. Saw this being discussed elsewhere in this thread.
And there are YT videos that call developers out for mushy textures on every new game release.
This is why some people love game streaming. Esp true if you only play a game once in a while.
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.
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
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.
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.
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.
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.
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.
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?
You too ignore this.
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.
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.
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.
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.
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.
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.
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
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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.)
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.
We’re stuck and getting stucker.
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)”
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.
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.
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.
30 years ago, nobody in their right mind would have thought "du'h, I'll just recursively scan whatever directory THIS environment variable points at and then apply whatever this library does to each file in it to get some list and then extract the files I need from that list"..
Even IF you had to do such a terrible and expensive operation, you'd at least have the good sense to save your result so that you can do it more efficiently the next time..
Imagine being a SWE working 12+ hours a day 6 days a week getting no rest. I might have accidentally coded something like this so that I could go home a couple of hours earlier.
I'd be wary with these kinds of words.
The thing is that people seem really, really eager to work in the video games industry. (Just like people are really eager to be artists or musicians or pet vets or teachers etc.)
Approximately everyone who programs for the game industry could also land a cushy job writing boring CRUD software.
I do admit that it's tempting to show compassion for people who put up with crappy working conditions and low pay in order to work in their beloved field.
(Especially if that field sounds socially desirable like teaching.)
But unless you severely restrict entry to the beloved industry, conditions and pay will always be lousy compared to what similar skills could get you in an unglamorous field. That's just supply and demand.
> Imagine being a SWE working 12+ hours a day 6 days a week getting no rest. I might have accidentally coded something like this so that I could go home a couple of hours earlier.
In the case of the game industry, more likely so that you could work on the next ticket during the eternal death march.
Game development companies are making millions in profits, what stops them from hiring 2x the workforce so that each can work 8 hours a day 5 days a week instead of 12 hours x 6? The demand in the field is obvious.
I personally would prefer ethically coded games if such a category existed. I get no fun from playing a game from a company that I know exploits people. Maybe that is the reason why indie games are so popular.
Would you say that Bundesliga footballers are exploited? They physically work much harder than programmers in the game industry.
> Game development companies are making millions in profits, what stops them from hiring 2x the workforce so that each can work 8 hours a day 5 days a week instead of 12 hours x 6? The demand in the field is obvious.
You can have a look at video game industry stock indexes. See eg https://etfdb.com/etfs/industry/gaming/ or https://www.investopedia.com/articles/investing/010616/top-4...
If there's evil exploitation and excess profit, they don't seem show up in returns to shareholders.
At least no better returns than any other industry. Including those with the cushy CRUD dev jobs.
Hiring a recent college grad and working him 12+ hours a day with no rest is IMHO exploitation.
This is why we have labour laws in the first place. Employers have too much power and influence. Offer a college grad the chance to work on games and above average pay, you get him on the hook. What you are not saying to him is that you'll overwork him breaching labour laws. I gave him a job, he wanted it, if he doesn't like it, he can leave is not sufficient to make it ethical nor legal.
Please read this insider story on how brutal the working conditions are: https://ea-spouse.livejournal.com/274.html
I cannot comment on the comparison with Bundesliga footballers, because I have no experience in working a physical job. I am a knowledge worker.
They don't give any thought to public investors such as you and me.
Funny coincidence, yesterday I posted a link which supports exactly your statement (even the 30 years): https://news.ycombinator.com/item?id=33018669
For some software, performance is important. For others, it isn't. Some developers are good, at least at making performant software, some are worse. That's always been true and will probably always be true.
We had lots of 'free' improvements in throughput. But latency still requires careful attention.
Perhaps we could justify it with new features at least? Perhaps my phone is slower now because the things in there are so much more useful now? Well, no. I got maybe a couple cosmetic changes, but functionality is exactly the same. My phone got slower for no benefit.
Apple for example barely mentions the fact that these services are running, and certainly does not give you any way to turn them off.
I think plenty of people would have made the error of filtering after applying an expensive operation than before. This seems like a classic rookie mistake, not an indication of some paradigm shift in thinking. What was impressive was that no one at Rockstar thought of improving the loading performance for so long that a use decided to reverse-engineer it.
Not only due to electricity, but also the high rate of replacing perfectly working computing equipment for higher-performing, only to spend any additional capacity running increasingly crappy and demanding software.
A valid point, but that just kicks the same question down the road: why was no engineer assigned to investigate loading times? That might be indicative of a culture that is biased towards projects with an outcome decided a priori. A lot of managers don't want to assign tasks where the definition of "done" is ambiguous.
Almost every employer also has a bunch of things they'd like you to do outside of your stories - mentoring junior developers, recruiting, planning, team building, professional development.
Some employers have SOC2 compliance policies that all changes should be traceable to a documented requirement, so fixes after the change is complete can be a bit more bureaucratic. If the project is behind schedule, the bosses might want you to work on something else instead.
Many developers are given pretty high-spec machines, so they can compile quickly and run weighty IDEs and so on - meaning an issue that's painful for users with 2GB of RAM and 2 CPU cores might be barely noticeable to users with 32GB of RAM and 8 cores.
And of course, some workplace cultures would say if you've 'got your work done' you can do discretionary performance work or you can leave early - and who'd choose performance work over spending time with their loved ones?
Sadly, the people I report to don't care enough about it. All they want is to push through the visible changes as fast as possible. And every single time these performance bugs come to bite us.
Our solution? Scale the system resources.
I'm not particularly satisfied with the work. But as an engineer I don't get to call the shots.
At that point, every developer on the team becomes an interchangeable useless warm body and the promotion goes to the "rock star" from outside who comes in and rewrites it or surgically fixes the top performance issues.
So in extension, optimization is terrible because we might be using the wrong abstraction level? E.g. it is hard to optimize a larger JS program, because if the developer specified some sort of detail it might throw out an entire class of possible optimizations.
There is actually an interesting presentation on the topic here: https://news.ycombinator.com/item?id=9396950 , which discusses among others whether a two-way communication between compiler and developer may help.
I can imagine the audio recorder is a low priority minor side project that gets handed from one guy (or team) to the next every couple of years, with the emphasis on "don't spend too much time on it".
The other issue is that performance is taken for granted; if something is slow, it's not immediately obvious.
I've often seen some dependency module be the bottleneck, and an in-house replacement that does just what we need can perform an order of magnitude or two better than a generic 'all things for all people' module.
Also there are things that work well for dozens or hundreds of data pieces but become abysmal when you eventually scale to hundreds of thousands. But no one else has that use case, so it works fine for them. And for those that do, by then the frog is boiled and they're used to it being slow.
A perfect example is windows 95 - wiggling the mouse causes a huge speedup in long running applications [0].
> used to always be about "tricking" the result out of the computer by applying deep understanding of both system and problem to find the fewest, most performant steps required to yield the result.
That "tricking" came with lots of issues. Massive security holes, significant app stability issues, and hugely increased developer time to implement things. I can get a hardware accelerated Sha1 hash of a buffer in one line of c++ today, and I know it will be correct.
People who do that work still exist. Computers are fast enough that it's worth not spending hours optimising for every allocation when you're displaying half a dozen strings on screen, but people like Casey Muratori, Bruce Dawson, still exist and still write code.
[0] https://retrocomputing.stackexchange.com/questions/11533/why...
And this attitude is what gives us such gems as the one mentioned in the OP article.
The difference is caring where it matters. Bugs and mistakes happen. The measure of someone who cares and someone who is improving is how they handle it when these issues happen.
But then they hardcode a whole Documents directory scan right in the UI thread in their own damn voice recorder app. Unbelievable.
“Looks fast to me! Ship it.”
“Looks fast to me too! Approve it!”
I think you’re giving programmers of the past too much credit.
You'll be amazed how many seemingly intractable technical issues aren't due to having been solved at higher layers of abstraction. Nowadays with things like clear cut ownership of post first sale ownership breaking down, we're actually getting bitten by having to try to technically solve problems, previously made tractable by the social consensus between professionals.
As a consequence, here we are with a now crappy, pathological Notepad.
We didn't used to have product teams as large as engineering teams. You can still engineer software the way you want, you're just beholden to some product persons idea about deadlines now. If you can turn your little unit of work around quickly no one will bat an eye (of course, we all know that's not realistic most of the time). If you dare trying to take longer than their perception of how long it ought to take then you better be prepared to discuss the "value add" of your performance minded solution as nauseum.
'Cuz why waste time doing something harder? Premature optimization and all that.
Honestly, in my experience, basically the opposite of the quote is true. If you want your software to be fast, you need to be thinking about speed in the design from the very beginning. Very hard, perhaps impossible, to make something not designed for speed from the beginning be as fast as something that was.
Of course there's a difference between having a holistic design that you know can go fast and immediately wasting time eeking out x% of speed in some random sub-fn that will only run y% of the time, when x and y are small.
But really performance does need to be built into the design.
(As an example, look at the heroic steps that are being taken to try to make the Rust compiler faster. It's slowly getting better, but it will never be fast. On the other hand, I would predict that if you started making a Rust-like-language from day 0 with a fast compiler as a goal, you could get something much faster.)
This is absolutely true in low latency finance.
> the right data structures
Isn't that just... doing the thing you intended to do, in the most straightforward way possible?
Who says "it's too much trouble getting the files in the directory I want, I'd rather search the entire computer and filter that list down to the files in that directory"?
This is like saying "it's too much effort to drive to San Francisco, so I'm going to drive to cities in California until I happen to arrive in San Francisco".
Eh. It's fast enough. And anything with overhead of borrow checker and focus on runtime performing, wouldn't be fast to compile either.
Biggest win could be getting rid of LLVM but that would have crippled its development speed.
Premature “premature optimization is the root of all evil” is the root of all evil.
Q "I'm working on high throughput data science thing, is branchless math better than conditional instructions here, because this thing needs to take less than a lifetime to finish"
A "You should focus on code readability, it's way more important ..yadeyadaya ... i work on python and websites"
I blame slipping standards in CS programs and the entire concept of "information science"
I've tried googling this, and I can't figure out what you're talking about.
It's important to be able to recognize which of the two echelons of problem-space one's codebase inhabits.
Defend Your Hot Path!
That is what the quote is talking about. I don't think you can blame the quote if people are just ignoring the first word, and I'm not convinced that's actually a common thing.
You shouldn't even need to profile to realise that if you're using a serial port for I/O, unless your hardware is something embedded and in the low-MHz, range, you'll spend most of your time waiting for I/O unless you massively overcomplicate your solution.
Premature complexity is the root of all evil.
In my experience it is mostly used as an excuse not to think about performance at all. "The quote says we can worry about it later!"
That's why the quote needs to die.
That's what Mike Acton says before he shakes your hand in the morning.
What's ironic is premature optimization is not just code, using K8s or expensive cloud solutions when a bare metal dedi will suffice. etc.
Instead it's just parroted by people who want to churn out MVP quality code in prod.
Agreed. I really dislike this excuse for sloppy slow code.
Yes, developer time is expensive, need to keep ROI in mind.
But if the expensive developer spents a week optimizing the function to make it 1 second faster, is that worth it? Too many people will respond "developer's time is expensive" without thinking beyond that. But of course, it depends.
If that function is being invoked millions of times per day by hundreds of thousands of people, it very quickly becomes totally worth it.
According to Brook’s famous paper, code reuse is the only way to significantly improve programmer productivity. No new language will suddenly make you 10x faster, and even that would be meaningless against all the quality code bases out there.
> developers to reuse layers and layers of packages and libraries whose behaviors are not well aligned with the goal of application, but hey, it's cheaper to just slap something on the existing packages
You could come up with data showing an R^2 of like 0.99 and there's always a smartass that immediately parrots "but remember that correlation does not mean causation". Ugh.
No one will say thank you for fixing something, but everybody will blame you if you fail trying.
Maybe there's a golden opportunity somewhere inbetween where optimization is not premature but also not painful to do.
As hardware gets better, we're finding ways to use it less efficiently. So if you want apps to become faster, you shouldn't be building better hardware. You should be changing human tolerance thresholds.
Which is almost impossible to pull off. Apple did this when they released the iPhone. Remember mobile apps before iOS? Mobile browsers before Safari?
When I started programming, people I learned from would optimise code in assembler, use clever algorithms and write highly unreadable code that was impossible to debug. One bit of code I remember interleaved various operations so that it's access would line up with disk reads. I rewrote it to just hold the data on memory. It wasn't much faster than his disk based code in practice.
But the only reason to go to that kind of effort was the severe constraints hardware placed on software. When those are largely removed, the imperative is to write code fast that other people can still understand.
In around 1990, I gave my dad my old 286 machine, with Win 3.1. He never upgraded it.
About 2000, when I was accustomed to much newer software & hardware, I used his old machine. I was amazed how much faster everything was.
I run Win95 and Win2000Pro in a virtal machine with old software and it runs faster than the most recent versions.
I put Ubuntu on a Lenovo PC and it runs faster than Windows 10 did.
There's still a couple quirks, but Windows 10 had its fair number of quirks too...
Oddly, with Windows 7 on the Core 2 Duo, the taskbar would randomly stop updating (I think it stopped happening after moving the same hard drive into a newer laptop?), and I got no end of driver issues: the touchpad would stop responding on the lock screen or logged in after sleep-wake, and audio would randomly stop playing until I restarted audiodg.exe. As far as I can remember, none of these issues happen on my Ivy Bridge laptop, where I'm clinging for life onto Windows 7 (the last version with a soul) for as long as I can keep apps running... though I'm getting rather tired of Tailscale creating a new network adapter and asking for home/work/public on every reboot.
I was, and am, blown away by how responsive it is. Plus, the UI sound effects add to the experience in a great way. You can HEAR when you've done something "in the computer." Just a bunch of clicks and boops. It's fantastic. Makes you think about what we've just... gotten used to.
The linux one was strange because my arch/systemd/ssd/i3 setup is lean, you get parallel boot, no heavy DE no bloat.. but everything felt lighter and faster on kali and I had a physical reaction saying "I don't miss anything from my current laptop, that old thing was closer to my needs".
Maybe a part of our brain that doesn't care about typography or visual effects much and prefer good old crude solid lag free tools.
Here you cannot really blame the poor developer, when the PM demands to scan all Documents, not just some relevant sound recordings. It's so obviously insane, that only PM's get away with this. Of course the dev matched our PM here, with his insane directory iters, but alone the idea must be appreciated first.
for(int i = 0; i < obj->GetNumItems(); i++)
doSomething(obj->GetItemAt(i));Imagine the cost of a non obvious RPC call in a nested for loop? Just not funny.
https://github.com/microsoft/WindowsAppSDK/issues/8
"The challenge here is simply that listing the StorageItems in a StorageFolder is incredibly slow and resource intensive compared to using the standard .Net/Win32 API to list the file paths. A quick test showed that in .Net it takes about 0.003ms per file, whereas with UWP StorageItems it takes about 2ms per file, which is around 700 times slower. Also, looking at the Runtime Broker, UWP uses about 70kB memory per file, which is a huge cost when loading 10,000+ files, whereas .Net uses around 0.1kB per file (that’s a very rough estimate)."
Somewhere else, someone proposes a theory that due to API mismatches/design issues in Win32 the RuntimeBroker is trying to use a design that isn't a great fit in order to try and provide certain security guarantees, and this requires pre-fetching a lot of data up front in case the app requests it. But NTFS is slow, so, all this additional traffic makes opening files via the Storage API really really slow.
The problem here isn't really "modern software", it's that Microsoft wrote a lot of new APIs over time with the intention of replacing Win32 (UWP/WinRT) but they aren't dogfooding them all that effectively, and they're using C++ for everything, so there are problems that don't get fixed for years.
If they do try it on their own system, they'll likely discount any performance hits as due to their own hording of files, and not consider the user likely to have just as many, if not more files. Thus, its not likely the programmer will notice it.
It's only if some exogenous event causes a programmer to consider run-time performance that it will be measured, and then optimized.
Bingo. This used to be a well-known benchmarking cheat, because performance on a full (or even once-full) filesystem can be very different than on a freshly made one. Almost as common as short-stroking, if you remember that. Anybody who wanted realistic results would run tests on a pre-aged filesystem. Cache warming is another example of a similar effect, and there are probably others across every area of computing. It's always really tempting to run tests in a maximally clean environment to get maximally consistent results, but that just doesn't reflect real-world usage.
So you end up dismissing slowness due to this ("I am sure this is faster when compiled in Release!").
I've made that mistake before until it was so slow that I decided to compile a Release build which was just as slow and found out that a regression was introduced.
Automatic performance monitoring for 'tasks'/services/computations is relatively straightforward but not quite as easy for UI interactions so these often get ignored.
In the 90s, we had shooters running at playable frame rates using software rasterization on a single thread. Now from this vantage point, think about the "what if you had a 1000x faster CPU" thought experiment that was posted to HN recently. Except, make it more like 100,000x faster...
If we had taken SIMD a bit further on the CPU and kept our extremely scrappy software engineering practices, I think it's possible the GPU might not have ever really emerged as a major consumer product. Recent game engine tech, such as Nanite's software rasterizer, is starting to shift ideologies back the other way now too.
I’m really skeptical about this take, the gains from the GPU architecture are too large to pass up on
Then came 3dfx, which was a blast.
You can even call the Amiga Blitter as one of the first GPUs, at least a specialized graphics chip. Same goes for coprocessors, like a math unit in a 486DX for example.
This is something I've considered a bit since listening to some Jonathan Blow talks. When you have loose requirements which change over time, limited time, and you're left figuring stuff out on your own it's difficult to do an outstanding job.
Nobody taught me how to write fast software. At best I learned enough to get stuff working. Usually after I've built something slow but functional I might've learned enough to write a faster version, but there's no time to do another rewrite because the features are changing.
For many developers the choice isn't between fast and slow, it's probably between slow or nothing at all.
Although I do think that big tech companies should be held to slightly higher standards.
Another key rule is to limit the "main loop" to as little as possible: don't run big computations which don't affect what the user is focusing on. For example, web browsers will pause and unload tabs when you have several of them: this means you can have over 100 open tabs and your web browser will still run fast, because the unopened tabs are not doing anything, they are just caching the URL and (in some cases) whatever is rendered on the site. Similarly, most games try not to render or update things outside of the player's vision. You don't have to go to extremes like this, but if something doesn't affect the user's flow (e.g. an extra feature only a few people use), its performance impact should be negligible. Specifically: don't put code in your hot-path that doesn't need to be there.
Another key rule is to use well-written libraries for your algorithms. I assure you a vector-math library with 1000 stars implements vector-math operations much faster than you can, and those operations are neatly wrapped in easy-to-use functions.
When you have code in your hot-path which needs to be there, is too slow and you can't replace it with a library, then you bring out the big-O and zero-allocation techniques. And also, caching. A lot of optimization is ultimately caching, as computation is generally much more expensive than memory. Those super pretty render engines all use a ton of caching.
You can have a piece of software with tons of bloat, extra features, inefficient/redundant computations, and an Electron back-end, which is still fast (example: VSCode). Even the Linux kernel has a lot of bloat in the form of various drivers, but it does not affect the main runtime as these drivers are not loaded. Even graphically-intensive games and simulations have redundant computations and excess allocations, they are just not in the hot-path.
And last tip: don't write exponential-time algorithms. The above doesn't apply when you have an exponential-time algorithm, because even when n = 30 it will slow your computer, and when n = 75 it will run past the sun burns out.
Sadly at that point rather more thought is needed and it seems to get a bit domain specific what needs to change next.
A corollary of this that bad architecture choices made up front, e.g. because performance was not considered, become both extremely entrenched and difficult to see on the flat flame graph.
Second, try to find out how fast software is written in the domain. These are often architectural decisions. Is this software better written by loading the entire data into memory? Or should I process it sequentially and keep memory usage bounded? What data needs to be kept "hot"?
Third, try to figure out what parts of the OS or libraries you use have potentially unbounded waiting. You don't want that to be in any thread that has to be responsive. Either make it async or run it in another thread. This is the cause of a lot of slowness in software, where it gets tested mainly on a single machine but it is actually a distributed system, or where there is never contention for a file in testing, nor is a database row ever locked by another application.
1. https://learn.microsoft.com/en-us/visualstudio/profiling/pro...
I'd say that in the vast majority of cases, you don't actually need to; what you need to instead focus on is how to make it not slow, and to do so is really not that difficult. In a word, it's (total) simplicity. The less code there is in total that the CPU has to execute, the faster it'll be. Thus, don't add unnecessary abstractions/indirections unless necessary, pull in huge libraries and use a tiny fraction of their functionality, etc.
I'm of the opinion that you don't need to know about cycle counting and such to write decently efficient software. You don't need to specifically optimise if you start off with a sane and simple design.
That's the same thing, worded differently. A junior programmer might focus on looping for-loops backwards "for speed" and then leave a serial `await` in the loop itself. If you don't see that that's a problem, no "focus" will help.
The more higher-level the language is, the less this is true in my experience
Most obvious example. Binary search is faster than linear, at the cost of more complexity (that can often be hidden under an abstraction).
Async code is often perceived as faster than synchronous, at the cost of more complexity. In the case of TFA, loading the file list asynchronously in the background could have been a good candidate for such.
Study parallel programming (that is, actually having two or more threads/processes/whatevers running simultaneously). This will help you understand the limits of parallelism in speeding up programs, but also the potential for some programs. You'll learn about how to divide work across N processors, the limits of performance gains, and where you will get performance losses (critical ones: synchronization and communication).
Study concurrency so you can see how to make use of asynchronous patterns. I don't mean strictly async/await style, just how to use whatever language/OS facilities to avoid unnecessary blocking. Like, if you're making a network query it can take seconds or longer to resolve (depending on location, size of the data, remote server load, etc.). Your program shouldn't wait if it still has other things it can do (if it doesn't, then let it wait).
Use a profiler, study your real systems and see where they spend their time. What functions get called the most, what functions or syscalls consume the most time. Is there a file/resource that's constantly being used? I once sped up a program by around 60x just by realizing that the previous coder was repeatedly reading from the same file. It wasn't needed, he could have read from it once (optimal), or at least cached it in memory (though memory wasn't so plentiful then, it would've been a tight fit on a mid-00s desktop, but fine today). Apply the ideas above to analyzing it and improving it.
Sufficient attentiin applied to parallelism/concurrency, is indistinguishable from management, without any of the benefits or recognition, or most other practitioners bothering to even try to to grok it.
Does that mean you shouldn't do it? No. However, there comes a point where if you breach that barrier, you will discover that the fundamental problems of today arise out of willingness to inflict pain stemming from the component actors in the Human Virtual Machine.
Learn how to use a sampling profiler.
I honestly have no words for this. I can't decide if I should laugh or cry.
What on earth is going on in the computing industry? Did all the smart nerds get siphoned off to hedge funds and machine learning, so Microsoft and Google can only hire the dregs to write boring desktop software?
Nowadays I feel there are a lot of people who got into computing as a career but don't really care. And management is trying to convert software development into a micromanaged sweatshop with easily replaceable people.
The number of TPMs and co-PMs (both Product and Project varietals) has exploded. There are now "group program managers" and of course all of these no-hard-product-artifact roles have formed hierarchies, so it's now possible to be a senior technical program manager managing other technical program mangers, the real work-product of which is purely additional meetings. Sub-par software engineers now have tons of places in the org structure where they can move laterally to maintain a place in tech - usually by inserting themselves between technical groups.
Thus, the ratio of people-who-can-produce-something-in-the-product to people-who-mostly-use-email-jira-slack-and-${videoconf} has plummeted.
Any non-trivial engineering product requires organizational members, but there's administrative bloat in tech to rival academia.
I suspect that many of the egregiously bad examples here are, rather than the product of a small team of terrible engineers, actually the product of several large teams of engineers being mediated by pseudo-technical people lodged in bureaucratic seams. That's how the worst software I've personally seen has been produced.
For instance looking at coffee machines, the general direction was:
- no machine, or decent but not so advanced machines - super basic machines, or advanced but finicky machines - crappy capsule machines, or super advanced finicky machines
Depending on how you look at it, there is a path from "advanced but finicky machines" to "crappy capsule machines". Personally I think things still improved, even as the low end is still crappier than the middle/high end from decades ago.
They’re grinding leetcode and getting a new job every ~1.5 years.
What happens when owning a home and starting a family near your employer is hard and gaming the interview process is easy.
While I don’t think company loyalty is warranted, I can’t understand why there aren’t much efforts to retain them. Like matching your current employees with market rather than letting them feel like they have to job hop for a better pay.
But right now, Electron remains a solid choice if you want to ship cross-platform desktop software without overextending on budget and time. Moreover, it's possible to make Electron apps that aren't terrible if they're optimized enough (Discord, VSCode, etc.).
PDF software is a different ball game as PDF is a behemoth of a specification. Did you know you could envelope 3d models within PDF files? Obviously a stripped down implementation (which you should use, if you don't require the fancier parts of PDF) will be snappier.
PDF has a lot of features, but it’s not complicated. If your PDF doesn’t contain a 3D model, that’s just some code that takes up room in the library but probably doesn’t even get paged in. A PDF is just a command stream, and the commands for drawing text are straightforward: https://www.oreilly.com/library/view/developing-with-pdf/978...
As to cross platform software, what about Qt, or GTK, or WxWidgets? There isn’t a single decent Electron app. Even VSCode uses CPU sitting there doing nothing. It’s a freaking text editor, what’s happening in the background?!
I'm not sure about, Acrobat reader in particular is very complicated, I'll rehash a famous old reddit comment --
Acrobat doesn't just read PDFs, it's a mail server, document lifecycle management system, DRM client, full-fledged document tracking system, it can have forms, it can gather statistics for your docs when you share them, it has audio and video playback. The manual is a couple thousand pages. Adobe's proposition to businesses is "You want a complete content tracking system? Wanna be able to effortlessly conduct surveys? Get next-level telemetry data from your users? Have we got the thing for you... the best part is all of your clients already have it installed!"
So good on you for ditching Adobe and not enabling this bull, SumatraPDF/emac's pdf-tools is perfect.
Regarding native GUI toolkits, they work but they're more work than Electron to deal with. Secondly, the big thing that us nerds keep failing to recognize is that software needs to be easy to use for grandmas and grandpas, part of that means having consistency in UI for users across the board from one system to the other. See how Zoom is nearly identical when using on iPad or Windows 7 or even Linux? Couldn't pull that off with GTK. I think with Qt you can modify your widgets quite a bit but you still don't have control over the minutiae of UI like you do with Electron.
Don't get me wrong it is still the wrong choice many times; the abomination that is MS Teams and Spotify is a flagrant violation of good taste and should be set on fire and nuked out of the fucking orbit, it is a heinous crime especially for big companies with the means to arrange large teams to build and deploy apps made with non-WebView-based frameworks, but for small shops I don't see any issue with Electron's use. VSCode launches instantaneously on my M2 Macbook Air. Zoom works flawlessly, along with a host of other Electron-based apps. I don't care too much if it's using some CPU here and there if I can't discern any slowness. Anyway, apps made with Tauri are much better in terms of CPU and memory usage, 1Password moved from Electron and Tauri and I'm certain more will follow and the next wave of desktop apps will surely be speedier now that Electron's slowness has become a bit of a meme.
Actually, PDF is not that bad at all. Sure, it has gotten some additions over the years, but even those are not actually too foreign to the original design.
Okular also comes with a per-page cropping mode, though it tends to cause issues when scrolling between pages. I prefer to use pdf-crop-margins (and on encrypted PDFs, qpdf --decrypt so pdf-crop-margins can read them) to generate a pre-cropped PDF that works on any reader, but keep the original PDF around for when I like it better.
Another trick is that on large 32+ inch screens, you can use Firefox's pdf.js in horizontal scrolling view to hold 2-3 pages on-screen simultaneously and cross-reference them easily, then switch to the hand tool for easy continuous scrolling.
Windows force-updated my Notepad.exe to the new modern UI version.
It is very visibly laggy for basic actions such as opening menus or scrolling through text.
You have to be spectacularly bad at programming to make something so basic so slow in 2022 on a very high-end gaming computer.
Not just bad, but utterly oblivious. Casey Muratori excoriated the Windows Terminal dev team for failing to achieve a consistent 60 fps when displaying fixed-width text, which is such a trivial exercise that Casey whipped up a demo in like two weekends. [1]
Now the Notepad team insisted on following in the Windows Terminal team's footprints and slowing down the other fixed-width text app that needs to be lightweight fast for all sorts of reasons. Nobody needs Notepad to be pretty. Everyone needs it to work.[2]
Just amazing to see something like this happen. It's like a slow motion train wreck, ruining one Windows app at a time.
[1] These videos are especially "shocking" because the code he wrote is terse, straightforward, lightning fast, and more correct than whatever madness Microsoft was doing.
First weekend: https://www.youtube.com/watch?v=hxM8QmyZXtg
Second weekend: https://www.youtube.com/watch?v=99dKzubvpKE
[2] For example, opening a 300 MB log file takes a solid minute of time, which is absurdly slow. It also bloats this to 800 MB of memory usage. For comparison, TextPad opens it in 5 seconds and uses 30 MB of memory. VS Code, an electron application(!) opens in under 2 seconds.
look at that- with so many wonderful words to chose from, why do people fall back on 'decimated' ?
Practically “Saw”, in real life.
https://www.merriam-webster.com/dictionary/excoriate
https://www.collinsdictionary.com/dictionary/english/excoria...
VS Code, which is an Electron application, opens text files something like 20 times faster than the new Notepad.
Whoever wrote and shipped the new Notepad should feel ashamed at their failure as a professional software engineer.
This isn't some Github toy project. It's being forced onto billions of users, without the slightest bit of quality assurance or adherence to the basic practices of the art.
Steady on old chap. Who's to say the hapless developer isn't embarrassed about things themselves, but is prevented from doing the right thing by some management edict, ancient process etc.
My money's on that rather than one person's incompetence.
And they should choose possible homelessness?
The original claim was that they were a failure.
The hypothetical is that they are not a failure, but are "prevented from doing the right thing". In the hypothetical, they should quit and get a new job.
The new Notepad is not fit-for-purpose. You cannot use it to open a file several gigabytes in size. It'll just die, take minutes, fill memory, and even if it opens successfully, it'll be unusably slow.
It's the Windows equivalent of 'vi'. It has to work, all of the time.
I hate this argument so much
It's like being perfectly fine with a universe with as much suffering as long as no one is dying. I am exaggerating of course, but why inflict this suffering to a BILLION people? I feel bad when I annoy someone for a few seconds (like struggling to open a door) and yet people are perfectly nonchalant to create ecosystem that billions of people use everyday for the next decade at least.
Are you sure?
---- "Larry started to explain about some of the places where he thought that he could improve things, but Steve wasn't interested. He continued, "You know, I've been thinking about it. How many people are going to be using the Macintosh? A million? No, more than that. In a few years, I bet five million people will be booting up their Macintoshes at least once a day."
"Well, let's say you can shave 10 seconds off of the boot time. Multiply that by five million users and thats 50 million seconds, every single day. Over a year, that's probably dozens of lifetimes. So if you make it boot ten seconds faster, you've saved a dozen lives. That's really worth it, don't you think?" --- https://www.folklore.org/StoryView.py?project=Macintosh&stor...
In fact, I have done similar things.
For example, I was asked to develop a protocol-shim for an authentication system used by tens of thousands of people accessing one of the largest SAP systems in the country. I wrote the code, tested it, and said to the PM that the only thing missing for go-live is some HTTPS certificates to make it secure.
He asked me to go to production anyway to meet his deadline, and that the certificates will be fixed up later.
I straight up told him: "No."
The look on his face was hilarious. He called my boss, my boss' boss, and up.
I told all of them: "No."
We waited for the certificates to be issued.
whoa there, you don’t know that. you think you do because you’re getting a ton of upvotes and you’re leaning into the feeling you had when you wrote that comment — the anti-Microsoft comment on a site known for its anti-microsoft comments.
if you don’t work at Microsoft, you have very little hope of understanding the motivations of a team, a product manager, or even a single developer within Microsoft. there’s a lot more there than meets the eye, just like there is at any huge company.
I do know what Microsoft is or isn't doing.
The evidence is in the pudding: opening a large text file in the new Notepad is orders of magnitude slower than any other editor on my system. This is a common failure mode that is trivially caught by testing. It's a well understood problem space, much like how databases "get slower" as the data volume increases, but the well understood solution is to use indexing to make this not occur.
The fact that the Notepad team spent months (years?) working on a trivial text editor and never tested it with text files speaks volumes.
If they had ever opened a large text file, they would have immediately noticed that a mistake had been made. Much like how if a database developer runs a query over large amounts of data, the missing indexes are immediately obvious.
It takes a minute for Notepad to open a file that isn't even "huge".
A minute isn't slow. It's broken.
They shipped broken software to the public, at the scale of hundreds of millions or even billions of users.
> understanding the motivations of a team, a product manager, or even a single developer within Microsoft.
Clearly, performance and quality are never motivations at Microsoft.
Their motivations are irrelevant for an end-user. Their results are.
If you don't think it should, I remind you that you can't take the humanity out of a human.
You really don't do your argument any favours with exaggerations like this.
At least you could thank Microsoft for being backwards-compatible.
I've done this with calc.exe since ~Vista.
the Notepad team
That's probably part of the problem --- Notepad is something that could be written by a single person in less than a day (it's not more than a wrapper around a Win32 multiline editbox.) Yet give a whole team of multiple people the task of "modernising" it, and work will magically appear to fill the available resources.
I tried it. Everything in the File Open dialog got disabled except for the cancel button for about 30 seconds until it loaded. For comparison, curl took 2.3s (250ms in later runs so probably waiting for curl to load) and my browser took around 250ms with cache disabled as well.
Why does it take Notepad so long?
That said, I've not encountered the same slowness issues since updating that are discussed here. I'm not a fan of the menu animations, but it's a minor nitpick. For editing huge texts it is significantly more efficient, in my experience. I remember turning off word-wrap in the old notepad after loading a huge log file, then having to wait minutes for Notepad to become responsive again.
Yeah, I know, anecdata....
Edit: The source code to the older Notepad is rather easy to find online. I won't link to it, but it's an interesting read.
The WinUI parts and initial launch cost, however, are somewhat hard to forgive.
I don't understand why desktop app user interfaces aren't blazingly fast and 240fps.
That being said, I think current iOS and macOS can run their UIs at 120fps (and Apple devices still seem to have decent battery life.)
Sure there has been, in the form of the nvidia path rendering extension. https://developer.nvidia.com/nv-path-rendering
It works great, on nvidia cards. Adobe Illustrator on Windows makes good use of it. Calling the extension from C/C++ and Python is no big deal.
Bitmaps are much faster to draw and can be made pixel-precise up front. With vectors it's easy to have pixel cracks or blurry lines because it's offset .5px.
yes, but that alone doesn't require that bitmap graphics be used.
> With vectors it's easy to have pixel cracks or blurry lines because it's offset .5px.
only if your renderer or your artwork isn't done correctly; inkscape used to be notorious for floating point rounding errors showing up with very few manipulations of a shape.
it's also been very easy to very quickly rasterize vector graphics for some time. maybe not fast enough in the past I guess, but computers are certainly fast enough now.
I look forward to a time when UIs are just all vector all the time, and it's the monitor itself which rasterizes, thanks to a program that the attached device uploads as it boots up or as the monitor is connected.
it's going to get more and more difficult to continue increasing display resolutions and refresh rates over long inexpensive cables if we continue to rasterize on a computer and push raw pixels to the display device.
Unfortunately, even if you have very fast drawing, there are plenty of other ways to make software slow. But high performance GUI software is the main thing I'm working on at the moment and I expect to have interesting results in the coming months. If nothing else, it should be a data point of how fast GUI software can be.
Unfortunately it's not this simple. Unicode and multilingual support means you can't possibly generate a single bitmap to contain all possible characters. Modern UIs (including text editors and terminals) generally support various zoom levels, which requires re-rasterizing glyphs at different zoom levels. This means you typically have to rasterize vector graphics (your font) on the fly as needed and then update your bitmap.
Edit: Also, emojis and certain scripts require composting multiple glyphs together. This means you have to figure out which glyphs are required for your codepoint and use your font metrics to composite the glyphs appropriately. Then throw in mathematical notation and all bets are off.
My point is, rendering text is not a simple done deal, but it's also not an impossible feat and it can be done efficiently.
vector graphics are not rendered directly to the screen. fonts are rasterized first, then the rasterization is what the GPU receives.
What difference does it make if you're caching the rasterization or not? You're still rendering vector graphics. And you're not just rasterizing once.
Modern font renderers can't get away with rasterizing glyphs once and reusing them anymore than arbitrary vector graphics renderers can. I sure hope my vector graphics editors cache the rasterizations instead of re-rasterizing needlessly.
it's not every frame. that's my point. that you missed twice because you can't see past details to the point of the statement.
lmao welcome to HN, if you don't enjoy that experience I don't recommend you try to argue here.
> figure out which glyphs are required for your codepoint and use your font metrics to composite the glyphs appropriately.
this is all done in shaping though, the renderers just see "put this thing there" and (at least in GTK) we just maintain texture atlases that are updated on the fly.
you're correct that it doesn't solve the same glyph at lots of scales though. but glyphy does (and at high FPS too).
To be clear, I'm not bashing on GTK. I'm saying that it definitely isn't as simple as the above comment implies ;)
the bitmap stuff still has major drawbacks though, like maintaining grid alignments and pixel boundaries where as this stuff (mostly) goes away using glyphy.
still work to be done around hinting though (hence not merged).
Also, on Windows, the "acrylic" thing is a circus show. Every app behaves differently. It also manages to sometimes lag on an RX5600. I know it's an "old" gpu, but still...
But in most contexts, it is not necessary to render vector graphics 'live'; caching is acceptable, so this should not be a bottleneck for most desktop software.
Keeping startup really fast and all interactions really fast is more challenging than it seems.
This is not the whole story, but one example of the differences in perception.
There are game-like UI libraries (https://github.com/ocornut/imgui) but to use them you have to write your program like you're a gamedev and Conway's Law usually fights that.
1. Avoidable: The main one here is shader caching. Shaders could be precompiled for every supported card/driver, but that's more work than anyone is willing to do. Even so, some games (like Rust) have an excessive amount of shaders, which adds a lot of extra waiting time.
2. Unavoidable: The main one here is textures. If you want it to be quickly accessible in VRAM, then it's going to be uncompressed, which means either having some very large files to copy over, or having some semi-large files to decompress. You can save quite a bit of time by micromanaging the texture resolution of each asset to be just high enough. Apart from textures, you have vertex data and other assets; all of which have basically the same considerations.
When it comes to regular software, most UI designs don't have big assets. They aren't loading billions of triangles or thousands of textures. This means there really isn't much need for long startup times.
Telemetry back to HQ takes resources.
I began to notice my disk drive light flickering regularly even when I was doing nothing with the computer, and the computer started seeming sluggish. I'd look at the process list, and started randomly forcing them to quit. Suddenly, the drive light stopped flashing. I'd found my man.
Googling the name of the process, it belonged to a program I'd bought that served media files to my Roku box. But I wasn't asking it to stream anything at the time.
I didn't know what the hell it was doing, but couldn't justify it, and removed the program.
Maybe it was indexing.
The same critique for Apple applies all the time, when you are completely vertically integrated and make your own chips up to the very software running on them, it's kinda easier.
That aside, there's no display offering above 60Hz IIRC in the Apple line. Correct me if I am wrong.
game development is an entirely different paradigm than enterprise software development; they aren’t really comparable, other than they both produce software which successfully executes.
in games, any code which does not directly contribute to the final product is not written, or is removed after it is not needed. in enterprise software, tens of thousands of lines of code are produced simply so the project layout is familiar for everyone working on it, because that’s important, somehow?
Casey was right to complain about the performance, and to show them how it should work. licensing it so that they couldn’t even look at it was both 100% intentional and 100% a dick move, and i will not credit him for that. that code could have been used as a wakeup call regarding performance for a lot of people within Microsoft, but he licensed it so they can’t even look at it.
perfomance of microsoft software isn’t great, i’ll agree. poking fun at them then hiding the code that was easy enough to write for him, but completely not obvious to the Windows Terminal team, doesn’t really make Casey the Software Quality Hero you’ve portrayed him as. Casey writes excellent software, don’t get me wrong. this particular example and series of events is not a high point in his career, to me.
it is when you know that Microsoft employees are forbidden from looking at GPL code because they may unconsciously recall it and use it in a Microsoft codebase.
Casey knew that at the time and admitted to licensing it GPL for that exact reason.
That is a “dick move” to me. maybe i’m wrong. you be the judge, i guess.
so difficult that he wrote it so he could demonstrate how easy it is.
he gladly showed the rest of us how to do it, and he intentionally took action which prevented anything he did from being used within Microsoft. Microsoft is so shitty because they don’t know [thing] so i’m going to show everyone but them how to do [thing].
he could have chosen to help. he chose to not help. he chose to complain and ridicule while intentionally avoiding doing anything to change the situation he was unhappy with.
they were not caught using his solution. they published a blog entry describing that they were made aware of performance problems and they didn't mention him. it was rabid fans of Casey that started foaming at the mouth then, even though Casey publicly stated he didn't want or need credit, because the idea wasn't his to begin with.
For anyone interested about the blog post drama check https://twitter.com/cmuratori/status/1522468481135902725 (hn discussion: https://news.ycombinator.com/item?id=31284419)
Personally I think that he owes them nothing, especially after the way he was treated in https://github.com/microsoft/terminal/issues/10362 so I can't comprehend statements which claim that he was an asshole for using GPL.
I'm saying he could have helped the situation, and he deliberately chose to not only avoid helping, but to hinder anyone at Microsoft who wanted to look at that code and contribute to Windows Terminal. That was a choice he made intentionally.
He could have taken the high road, there. He chose not to. It's his choice, don't get me wrong, he was well within his rights. I just disagree with that choice. that's why I call that a "dick move". And if you disagree with me, that's fine. "Dick move" means different things to different people at different times.
He was right, but he does not seem remotely pleasant to work with and has been remarkably adversarial. Hasn't exactly fostered a "let's hire him as a consultant" relationship.
Isn't that exactly what Copilot does?
no, that is not what copilot does unless you check the box (or fail to uncheck the box) that allows exact matches of code from public repositories.
https://docs.github.com/en/copilot/configuring-github-copilo...
actual users of copilot seem to know this little bit of information; commenters who like to make comments about things they have never used always overlook details like this, and perpetually restate the things they learned about the topic months or years prior, even when those details were incorrect at the time, and are still incorrect today.
I see. But the setting (which surprises me that is opt-in) merely checks whether the output is an exact match and forces the system to produce a new output. The system can and does (as seen on the tweet) output verbatim code. So the question that parent commenter asked is legit.
You seem to roughly agree with this in your 3rd paragraph. Enterprise software is fucking awful despite spending an enormous amount of money on it, and that's because the developers and the development process and the SMEs and the managers and vice presidents are all fucking awful at their jobs. That's the reason. They're fucking shit-ass at making software. Just look at Microsoft Teams. This is not the defense you seem to think it is.
Besides, we're not talking about enterprise software driven by bloat from the demand-side. We're talking about notepad and the console.
Marketing and legal is stellar though.
Enterprise software written 20 years ago still runs and works. I can still install it from an Msi package
Half the android apps I bought 5 years ago don't exist any more.
In Google they would have cancelled, closed, relaunched and cancelled again.
Games are hit and miss, admittedly some run for decades.
But above all, they dont care
PS: you wouldn't believe how many tries it took to get my phone to accept the word "cruft" instead of autocorrecting it to craft. Dammit!
it’s not a defense at all, it’s my whole point.
enterprise software is absolutely lost, because following enormous sets of rules and enforcing those rules via management is FAR CHEAPER AND EASIER than hiring skilled people who don’t need those rules to produce good software.
if that isn’t the very definition of bad management and business practices, i don’t know what is.
enterprise software being a total shitshow is my point, because a shitshow is far better for shareholders in the short term. filling seats with dopes you hope to train is easy to measure. carefully harvesting the best talent is slow, expensive, and difficult to measure.
microsoft does that. all large publicly traded companies optimize for short-term gain at the expense of long-term loss.
game companies, the good ones, the smaller ones, don’t operate like that. there are shit managers there, too, but game companies attract the exact talent they need, almost by default. they care about what they create because not caring means bad reviews, low sales, no bonuses, and layoffs.
the punishment for writing shit software at any enterprise company is continued employment, and at worst, an involuntary lateral move to another position where software quality does not matter.
microsoft is an enterprise software developer. they are burdened with that management style just like a lot of our employers are.
I hear this claim all the time, but nobody is able to explain why they continue to grow profits.
It's because people like me don't care about user experience.
We get Teams for free in our M365 subscription. It's integrated with other stuff, it has APIs for automation and I can't be blamed for choosing MS.
I know this is a shitty argument... but seriously, I have many battles to fight, not wasting my energy choosing the best chat software.
Devs think a lot a about software quality and stuff, but that's often irrelevant for business. GP is wrong, MS knows exactly what they need to do to increase profits.
what it isn't is investing in quality and long-term success; it's betting that you'll be able to find some other short-term optimization in the future, and it relies on the stock market having a memory that lasts no longer than one year
> and it relies on the stock market having a memory that lasts no longer than one year
If that was true, you could easily make $billions shorting those stocks that you know sacrifice the long term. Let us know how it goes!
Everything Microsoft did in the 1990s was based on returning profit sooner rather than later. That's the whole point of "embrace, extend, extinguish": liquidate this technology and turn it into money as fast as possible.
Every time you make a decision which gives you money or profit today, and that decision is based on money alone, you are optimizing for the short term at the expense of the long term.
It is easier to think about when you think of personal finances. You can have a slightly bigger paycheck every pay period or you can set aside money for retirement. You can maximize profit today if you borrow from your own future.
I should not have said that Microsoft do this exclusively (and at this very second I'm not sure I said that) because they don't do that exclusively. It is a common approach to decisions regarding stock price and "shareholder value" however.
Are you aware of what happened to MSFT stock during the 1990s? The claim is not credible.
> It is easier to think about when you think of personal finances. You can have a slightly bigger paycheck every pay period or you can set aside money for retirement. You can maximize profit today if you borrow from your own future.
This is not what "profit" is.
optimizing for short term gain IS OPTIMIZING TO MAXIMIZE PROFIT IN THE SHORT TERM.
If your company does last long, and grows enormously, you are optimizing for the long term.
being a public company and having shareholders more or less requires you to increase stock price at the expense of almost anything else.
investors do not care if a company goes under, provided they get a handsome return on their investment beforehand.
Can be fine. There are plenty of computer game genres where security bugs are not fine at all and where you need to be super careful to not introduce nondeterminism as that would break the whole game, all while maintaining performance.
yes it does seem perfectly fair, doesn’t it? it isn’t. the amount of work that needs to be done always outscales the ability to do the work, forcing prioritization. the Windows Terminal team is not large, and just throwing people at the team will not make it faster.
> "They don't have the experience to make it good" is pretty chickenshit.
you’re very unpleasant already. second sentence, calling me chickenshit. classy.
how many people do you know who are capable of writing what Casey wrote in two weekends who also DON’T work on games full-time?
i don’t know any people like that. so, where do you think those people go to work? on Windows Terminal? like that’s a common career path for someone like Casey? i would be absolutely flabbergasted if there were someone on the Windows Terminal team who knew how to do what Casey did before he did it. “Hey, come work on the command prompt” does not attract people who understand how to dynamically generate a texture atlas of code points and use that atlas to render a texture representing the console window contents 60/120/144/240 frames per second. the people that know how to do that are already spoken for.
I have no idea who could match what, but Windows is just an utterly massive product, they have the resources to make the whole thing shine, even if people really don't want to work on it and need big bribes.
THAT is precisely the problem!
What Casey did was not some unique and special solution known only to dark wizards working on AAA game engines.
It's an obvious solution that has been implemented many times before by many people for many systems. All green-screen and DOS-era terminals work this way, for example.
Admittedly, I'm a former game engine developer, but I went into that career with essentially zero industry experience of any type. I just muddled my way through a C++ textbook and started writing a game engine.
I needed a text console for my game engine, and I also needed to display Unicode text because we were targetting an international market.
Completely naively I wrote a "text engine". It took about a week, and my solution was virtually identical to Casey's. The difference was that I was slower at implementing it, and Casey's is more feature complete, but the approach was identical.
I didn't go to Hogwarts School for Game Development Wizardry. I just thought about the problem and applied the obvious solution.
The difference between people like Casey and the Microsoft team is not necessarily aptitude, but attitude. The Microsoft team has no mechanical sympathy and no interest in quality.
They made arguments not just along the lines of "this is impossible", but also "nobody needs this".
Through every fibre of their being they believe that computers are slow and that this is fine.
lol no they do not. absolutely not lol
> The Microsoft team has no mechanical sympathy and no interest in quality.
I know people at Microsoft. I have acquaintances on the Windows Terminal team. this is just plain factually incorrect.
Those character generators don't do rescaling and linear interpolation of the texels, and often they're only one-bit color, but that's extra work refterm is doing that DOS-era terminals weren't doing. It wasn't that Muratori invented a new, more efficient way to do things; he just reproduced the bitmap character-generator approach that was standard from 01975 to 01985, but runs it on faster hardware. So he got about 160 megabytes per second before optimizing, ten times faster than Windows Terminal, and 1600 megabytes per second after he "put in the most basic optimization [he] could think of".
It isn't necessary to do character generation on the GPU to be responsive, either. The Alto running Smalltalk took maybe a second for its ≈0.5 MIPS CPU to redraw a screenful of proportional text, say about 2kB. The original Macintosh took maybe 100 ms using a 1-MIPS CPU and hand-optimized assembly. But the laptop I'm typing this on is about 34000 MIPS so it ought to be able to do the job in ≈3 μs. My word-wrapped proportional-font experiment in http://canonical.org/~kragen/sw/dev3/propfont.c gets 72 MB/s, which works out to ≈30 μs per 2-kB "screenful". Valgrind says it's running about 113 instructions per byte rendered, suggesting my C is closer to Smalltalk performance than QuickDraw. It's still 20× as slow as refterm but it's not using the GPU, but 5× as fast as Windows Terminal. (On the other hand, it doesn't draw to the actual display, just a memory buffer which it outputs to a PNM file at the end.)
My own unoptimized monospace terminal emulator running on the CPU with a full-color font https://gitlab.com/kragen/bubbleos/-/blob/master/yeso/admu-s... takes 6.9 wallclock seconds and 3.1 CPU seconds to display the output of yes {1..90} | head -c 1000000. This is enormously slower, only 145 kilobytes per second or 323 kilobytes per CPU second, a whole 14 milliseconds per 2-kB screenful. (And its screen really is 2 kB.) This is 1000 times slower than refterm and 100 times slower than Windows Terminal, and it still doesn't handle the difficult cases like combining characters, double-width CJK characters, and RTL text. Probably I should optimize it!
Regardless, this isn't about Casey. This is about MS releasing crap software. Text editors from 30 years ago were faster than WT. Something is horribly broken about the programmer's approach to writing code, or they are being horribly managed, or all of the above.
On the surface, it often feels like there is just an extreme lack of pride in workmanship. In code from lots of vendors I am constantly seeing interfaces with strange glaring issues, with bizarrely convoluted UI paths, with odd render bugs, etc... It feels like there is something unfortunate happening across the industry. Maybe I'm just a cranky older engineer, but seeing so many visual and functional failures being shipped makes me think the issue is far deeper than that.
https://github.com/cmuratori/refterm/blob/main/LICENSE
It’s just GPL 2.0, what are you talking about!?
Are Microsoft employees vampires that will burn up instantly if they merely glance at GPL code or something?
This is sour grapes nonsense from Microsoft. “We don’t like your tone so we won’t even dignify your argument by considering it.”
At one point an MS employee said they would love to fix their code as suggested by Casey but he refused to even look at the YouTube video!
“I would love to hear your arguments but I refuse to listen to the sound of your voice.” is next-level dismissive.
More like will legal drain life from developers if they hear they looked at GPL code.
We had to switch DB drivers because legal didn't want to deal with GPL. Imagine writing code based on it...
perhaps you are not familiar with what the GPL requires of its users, and how wildly incompatible that is with what a company like Microsoft does.
Microsoft employees are forbidden from looking at GPL code (as well as other virally licensed code) because they may unwittingly reproduce some GPL code they saw in a large Microsoft codebase.
If that happens, and they are taken to trial over it, and lose, that entire codebase is now GPL. This is enough of a risk to them that MS employees have computers which simply can not view GPL code.
that is also why they would not watch the video; it isn’t about his voice, it is about the code visible on stream. additionally, watching a video of GPL code being written could be perceived as an attempt to circumvent the restrictions on viewing GPL code, and would likely get the viewer into trouble.
you not already knowing this bothers me a lot, given all the things you’ve said in this discussion. you are making a lot of assumptions that are just not true and basing your opinions on the belief that those assumptions are true.
this is very similar to why software at microsoft is as bad as it is generally; a lot of people assuming they know things they don’t know, and producing results which are more flawed than they needed to be.
They're free to look at the approach and simply rewrite it.
They'd have to anyway to fit in with their codebase.
To give a very concrete example: french singer Claude François made the song Comme d'habitude: https://youtu.be/avr5nvY4wxg
It was translated and rewritten a few times but he still is recognized as one of the copyright owners on those covers, e.g. https://youtu.be/qQzdAsjWGPg which are definitely not just a mechanical rewrite of the original score
Well, at least unless you end up as big as Led Zeppelin was before someone catches you, I guess ;)
Are you talking about the Led Zeppelin who get entangled in judicial pursuits for plagiarism every couple years? If it was as clear cut as you say it is it would never reach any judge.
There is even one case where someone was condemned for not copying any specific song but the general style of another musician : Pharrell Williams had to pay 5M to the Marvin Gaye estate because of this
https://rpjlaw.com/blurred-lines-copying-songs-musical-style...
https://www.jonesday.com/en/insights/2018/07/blurred-lines-b...
Yes, this is extremely shitty but this is the world we live in
Yes, I intentionally mentioned a song "by Page – inspired by Jake Holmes": https://en.wikipedia.org/wiki/Dazed_and_Confused_(song)#Led_...
> The Ninth Circuit stated that the appeal was decided “on narrow grounds” and that the “decision does not give license to copyright a musical style or ‘groove.’”
What a pile of bullshit. I wasn't aware of that case.
I don't mean simply renaming variables or changing a couple of lines.
No.
Algorithms, being purely functional, are not copyrightable in any country that I know of. So a new implementation that uses the same algorithm as the original, but without copying any of its non-functional aspects, is not a derivative work of the original and does not infringe its copyright.
Cleanroom reimplementation is a defense against allegations of copying, because under, for example, US copyright law, access plus substantial similarity is sufficient to show copying. The "He's So Fine" lawsuit is one of the most extreme examples of this doctrine. Cleanroom reimplementations are a defense against copying by eliminating the access element. But copying the functional aspects of a program does not meet the "substantial similarity" bar.
If by "look at the approach" you mean the "look at the code", then no. You're giving a step for your code to be considered a derivative work. If by "look at the approach" you mean someone read the code, made a specification, and then someone else that hasn't looked the code, made a program based on the specification, then yes. But arguably this isn't "simply rewrite".
Those aren't even baseless considerations. ReactOS project had paused development due to concerns that derived (read: rewritten) parts of leaked Windows code may have been used. It took years for ReactOS to show that everything was in fact a clean-room implementation (basically doing what wrote above). If they hadn't, they'll have made themselves open to be sued by Microsoft.
You can not. So what do you do to prepare for a lawsuit which alleges that you've copied GPL code into the Windows codebase? You have technical and legal barriers in place so that those developers can't see GPL code where you can control that, and make them promise that they won't do anything to compromise the license of the Windows code that they work on. Technical and legal (read: contractual) measures to prevent this are the defense that one needs to have in order to defend against a case like this, in court.
So, because you, as a Microsoft attorney, can't guarantee that GPL code won't be reproduced verbatim in any quantity in the Windows codebase, you do what you can to dissuade your developers from looking at GPL code.
please think for 2 seconds on your own and I won't have to ELI5.
Also, Microsoft employees work on GPL2-licensed Linux just fine, so something seems off in your story.
stuff that is not Windows Terminal but that lives in the Windows Terminal repo on GitHub gets shipped with Windows.
so, yes, there are very good reasons they can't license Windows Terminal via GPL.
WSL kernel folks get that repo whitelisted.
Also, it's not just WSL people who work on GPL software inside Microsoft. I guess they are magically expected not to subconsciously reproduce any GPL code in their work ever ;)
Also, though, it does not require 25+ years of game development experience to figure out that you can write a non-laggy terminal emulator, which should be obvious because people have been building non-laggy terminal emulators since at least 01974 and people routinely watch 1080p videos at 60 fps on modern laptops and even modern hand computers.
We had terminal emulators with acceptable, even snappy, performance on X-Windows when I started using it in 01993. In 01994 I would commonly use an IRIS Indigo, which had a 150 MHz R4400, which was not superscalar, so it was maybe capable of 150 MIPS, or 300 MIPS if you count floating-point too. I preferred using it instead of the X terminals because it was faster. I'm typing this on an obsolete laptop whose CPU averages about 100 times faster than that. It's immediately obvious to the most casual observer that there is no excuse for software on this laptop to flub UI tasks the Indigo handled with ease.
The VT50 https://en.wikipedia.org/wiki/VT50 was released in 01974, and its microprogram emulated a Teletype with added features. (See my comment at https://news.ycombinator.com/item?id=32547666.) A service manual for the 01975 version, the VT52, is at https://news.ycombinator.com/item?id=32547666. It had 60 frames per second (in the US), 240 scan lines per frame, 80 characters per scan line (at 15.36 kHz), and I think 8 pixels per character (in each scan line), one of which was always blank. So its output shift register ("VSR") operated at 9.8 MHz, or actually a little bit faster because of the 10-μs HBI, during which it checked the keyboard. Its microprogram, which had to load the appropriate 7 bits into the VSR 80 times per scan line (as well as processing escape sequences and printable characters during, I think, the VBI), had a 1.3 μs instruction cycle time (770 MHz), divided into 18 72-ns clock cycles (13.824 MHz) during which it did different things.
So I think that in most 72-ns clock cycles about a couple of dozen flip-flops would change state.
This laptop typically executes about 2400 CPU instructions in every 72-ns tick of the VT52's clock, 600 per core. You could compile an RTL-level logic simulation of the VT52 into C and compile it with a C compiler, and it would run faster than the original VT52.
But that would be sort of stupid because you have a framebuffer and a GPU with texture-mapping units; your CPU doesn't actually have to generate pixels one at a time to keep the screen refreshed because you have hardware to do that for you. A 1920×1080 video at 60 frames per second is displaying 124 million new pixels per second, which it has to get by decoding H.264 or H.265 or something. That's a bit over 1.5 million VT52 characters per second. But when you're displaying characters on a terminal that isn't very useful because people can only read about 30 characters per second; even updating a full-page 80×66 display at 60 frames per second is only 0.3 million characters per second.
In most cases the computation required to process a character is to verify that it's a printable plain ASCII character, update the screen image, and update the cursor position. Updating the screen image might involve blitting some texture data or, as in Muratori's refterm, updating a glyph index that gets consulted by a shader to figure out what texture data to draw when the time comes to render a frame. We're talking about an amount of computation that's small compared to a typical C subroutine call and return.
no! it would not! the GPL is a truly awful license. "freedom" my white butt. it's a list of requirements, all of which restrict the freedoms and abilities of those who utilize it.
about rendering:
I'm not trying to say that it's hard. I'm trying to say that they believed they knew how to do it, when in reality they did not.
THAT'S ALL.
Everyone is laser focused on the details of what I am saying and completely missing the point of what I am saying, or trying to say. I am apparently speaking a language that is close to English but not actually English.
And having the Windows Terminal licensed under the GPL instead of a Microsoft EULA would strictly increase the freedoms and abilities of its users: they could still legally do all the things with Windows Terminal they do now, plus lots of new things as well. Opt out of undesired updates, for example. Even the Windows Terminal team would have more freedom that way: they could go work at a different employer and keep hacking on the code they wrote as part of Windows Terminal.
The only freedom the GPL restricts is the freedom to maintain a captive audience in a state of information asymmetry guaranteed helplessness.
You're not making a good case for yourself here.
if I license something with the MIT license, anyone can use it for any purpose, and they can take my code with their modifications private if they want, meaning those entities are free to do what they want, and the code I released is still freely available just like it was before. I lose nothing, and no freedoms were taken from anyone who uses my code.
That sort of simple numerical counting isn't enough for an ethical argument, of course. If my house is converted to a public park, then everyone gains the freedom to drink beer in it, or at least everyone in Buenos Aires does, and only I lose any freedom, like the freedom to sleep in a dry bed when it's raining without raucous beer-drinkers guffawing all around me. But this is still a net loss because the benefits to everyone else are not as important as the loss to me.
In the Windows Terminal case, the situation is the other way around: Nadella would suffer a loss of freedom that affects him only in a de minimis way, while everyone else would gain substantially.
Have you considered that people are disagreeing with you because you are wrong rather than because they don't understand you?
Surely you understand why something like this may be genuinely beneficial for application software even when it's not needed for games?
it's stupid.
You are moving the goalposts.
the result is very large projects because no one knows how to write code, and tons of unnecessary abstraction and boilerplate stuck onto EVERYTHING.
just write what you need to solve the problem you need to solve, then stop.
I will restate what many others have said here, Microsoft has used and interacted with GPL2 code longer than I have been alive. There is GPL2 licensed software in the Windows Store released by Microsoft.
Microsoft is the one doing the "dick move" by requiring special permission for new GPL2 interaction.
If Microsoft can interact with Linux, the biggest GPL2 project ever, they can interact with whatever Casey releases.
they can't adopt GPL in that repo and Microsoft has a very strong policy about segregation between developers who can read and write GPL code and those who cannot. those who cannot interact with GPL code get to work on stuff that ships with Windows, like the stuff in the Windows Terminal repo.
so, no. they can't look at GPL code, including Casey's refterm code. Casey knew all of this when he chose the GPL for that project.
As for the segregation policy, it sounds like a self-imposed problem.
Like others have said, there are organizational issues causing the company's output to be embarrassing trash. Personally, I blame the Ballmer years of "unregretted attrition", but that's just my pet theory as to how it became a dysfunctional bureaucratic treacherous pirate's den
(highly recommend Notepad3)
i don't miss the ceremony of trying to debloat Windows after every unstoppable auto-update; what a goddamn nightmare that was.
now permanently on EndeavourOS KDE/Plasma and everything "just works, very fast". i do wish that Affinity products where available for Linux, i dont think you can run them with Proton/Wine :(
If you asked me what a calculator app "should" do, none of those would ever enter into my brain.
It just keeps getting worse. I mean how hard is it to do nothing and leave these old apps alone?
there is fogies complaining about change, then there is making things objectively worse for zero gain. christ
and they are releasing a new taskmgr on win11 to boot
Which is borken. In the performance tab, I often see the right-hand side elements cut-off (like RAM size, etc) even though there's still space left in the window. Resizing it brings the text back.
But hey, at least it now supports dark mode!
Now they load up the monstrous libraries they need to negotiate a way to communicate with the desktop, and then negotiate that. A screen buffer is so yesterday, so I guess they have a scene graph now that some library renders whenever a pixel might have changed, triple-buffered to prevent artifacts.
If you don't like how your OS works, pick a different one.
2000 lines is nothing. I routinely edited book length texts in Microsoft Word for DOS on a 4.77 MHz 8088.
I would expect the changes to be visible ideally in the next frame, but I guess that’s not really an option?
The compromise would be to always start rendering immediately rather than wait x ms, but if you detect that the previous rendering hasn’t completed when the next input has arrived then you can start debouncing before rendering until you catch up.
If you mean that, I don't know how it relates to the comment/article since I never needed to do debouncing in a desktop context (only for embedded stuff with actual push button circuitry attached).
The classic example is a data table with a text field that filters/searches the results, pulled from a server.
Let’s say you want the results to update “live” as the user types, without having to click a “search” button. So if the user types “bacon” then she sees all results that contain the word “bacon” in them.
Problem is, if the act of sending the text field input to the server and waiting for the results is relatively slow and blocks the UI from updating, then each key press causes a delay between the search results updating on the screen, and the next letter showing up in the search field.
1. User types “b” and then the app sends “b” to the server, pauses, gets a response of all results with the letter “b”.
2. User types “a”, and the app sends “ba” to the server… pauses… gets results. She types a “c”, the app sends “bac”, etc.
Debouncing, then, means the app waits a short period of time to make sure the user is finished typing before sending the search term.
Usually this means every time the user enters a letter into the search field, the app sets a timer for, say, 500ms. If the user doesn’t enter another letter for 500ms, great - send the search term, wait for the results.
If the user does enter another letter within 500ms, then she must still be typing, so reset the timer back to 500ms and hold off on sending the search term out to the server.
When a user inserts to backticks, insert the closing backticks immediately.
And now explain how anyone can ever turn existing text into a code block if every user action is "modified" to not turn existing text into a code block.
> And now explain how anyone can ever turn existing text into a code block if every user action is "modified" to not turn existing text into a code block.
At no point did I mention that you couldnt wrap code in bacticks, I simply said the default insert would NOT have single pair backticks opening up to a forced re-render of every trailing element.
Markdown+ is parsing and rendering your Markdown in real time. It may be slower than it needs to be, I haven’t used it and don’t know, but it’s doing a lot more work than 1982-era MS Word was.
You can still get blazing fast speed for even gigabytes of Markdown if you use instead use something like BBEdit on a current Mac, which would be the equivalent modern user experience.
At least, they have fix it in the most recent version of windows ....
That's the point of gp's comment. The software is doing a lot of "work" that it does not need to do, thanks to poor programming.
Work is activity that helps to achieve a goal. Whatever Win11's Notepad is doing, it is not that.
If indeed premature optimization is the root of all evil, then I have lots to atone for.
If I'm actively editing a markdown file, I do not need for it to fire off a re-render on each keystroke. It can wait 500ms before starting to do it, and cancel if I hit another key in the meantime. If I start typing after it has started rendering, then go ahead and finish that cycle while still showing me what I type in real time.
However these events are scheduled, the appearance of my typed characters on the screen is going to always be the priority. There's no reason to block UI while doing this.
TB is a multithreaded program, but it isn't very good at using it effectively. I've learned through bitter experience to not touch a key or the mouse when it is getting messages.
Modern Word lags on a two-page document on an 8 core xeon with 64 GB of RAM. Same PC can run modern games at 4k@60 FPS.
I can agree that maybe modern Word "does more work" than Word 97. But as another commenter said: WTF is that work? And do we even need it?
As a user, all I see is that modern Word's interface has buttons all over the place, taking up half my screen. And when I grab the scroll-bar, it won't scroll until some time after I've released it. Word 97 managed to scroll the contents as I moved the bar just fine.
It also takes forever to start-up on an SSD so fast it can move multiple times the size of that old 486's whole hard drive in one second. WTF is it loading? And once loaded, why is it so slow, since everything can fit in RAM?
IntelliJ was killing me until I figured this out.
Applications are simply not well written and most developers are incompetent and unaware of how incompetent they are.
> opening a 300 MB log file takes a solid minute of time
But notepad.exe is always slow when opening large files. If anything I think it's better now than it was in XP/7.
Unless you're using the same hardware, that's probably all hardware improvement.
Media Player has apparently been replaced by "DVD Player(free)" which is not only intentionally crippled (you have to use the keyboard to access the DVD menu and if the Menu begin with no item having focus, you're SOL) but also crashes 75% of the time upon attempting to play the disk (I spent five starting the thing until I installed VLC).
The entire scheme is apparently to try to leverage the monopoly MS has on low-end systems.
Some (not all) of the lag in Windows is on purpose by the UI engineers. Google "disable windows animation" for a starting point on how to fix it.
Keyboard shortcuts, for example.
On my machine, Notepad still seems to have the traditional keyboard shortcuts. But in Paint they are completely missing.
Alt-F-A? No Save As dialog for you.
Close the app with unsaved changes? You get something like the traditional "do you want to save your work?" dialog, but the left and right arrow keys do not work in the dialog. And you can't type N or Alt+N for "Don't save".
These do work in the latest Notepad on my machine.
These keyboard shortcuts used to work in every Windows app, and especially in all the standard Microsoft apps. Now it seems to depend on whether the individual developer knows about them.
I'll give you an example.
I've seen developers and DBAs working on databases simply create new indexes on the fly to fix some performance issue. It takes ten seconds, it's fairly safe, and it is relatively easy to gauge the effect. "Before minutes, after milliseconds". Done.
I've seen other places where merely suggesting the use of an index -- no matter how beneficial, trivial, or safe -- resulted in everyone foaming at the mouth in abject terror. Wailing and gnashing of teeth. "How dare you suggest that we touch the mystical black box!? Begone with you, foul wizard!"
This is what I saw with the Casey Muratori vs Windows Terminal team arguments.
Everyone acts like Casey pulled out some dark tome only the most grey haired wizards are allowed to see and spoke secrets that Microsoft isn't even allowed to legally hear.
Do you actually know what he suggested?
Make a grid, just a 2D array. Put the characters in them.
Use the characters to look up small images of individual characters in another grid.
If the other grid is missing a characters, find an empty spot an replace it with the missing character image. (If the second grid is bigger than the first one, this is always possible.)
That's... it. Just array lookups, 2D images, and a hashtable.
This is child's play not wizardry.
When I was something like 23 years old, my boss told me to go help optimise IIS performance at a large dev shop.
Think about how absurd it sounds: A junior tech with essentially no knowledge of IIS performance tuning doing consulting to an entire company of 30-40 year old experienced developers on the finer points of web serving.
I turned up, and it turned out that these guys were writing what seemed like a trivial web app, but if two people submitted a form simultaneously then the page would take a minute to submit.
A minute you ask? I timed it: 60 seconds exactly, plus or minus a few hundred milliseconds.
That's a lock timeout.
I asked to talk to the database team. They told me the scope of works was to look at IIS and "tune it". To put things in perspective, they were using the largest server I had ever seen (8 sockets!) and it couldn't handle two users.
"Maybe we need a 16-socket server, what do you thinkg?"
I told them... no-no-no-no, I need to talk to the DBA team, just trust me.
After some negotiation, I finally sat down next to the "senior" DBA and asked him what database engine he was using.
"Sybase."
Shit. I had heard of Sybase, but had never used it. I had a smidge of experience with SQL Server, and I had heard that Microsoft based it off the Sybase code that they had licensed.
In a mild panic I asked him if Sybase had any performance analyzer tool or somesuch?
"No."
Err... that's not good. Now in a cold sweat, I asked to borrow his mouse for a second so I could click through his Start menu, where I found the Sybase folder, with a "Profiler" tool that was a carbon copy of the "SQL Server Profiler", except for the icon and some color schemes.
It took about 10 minutes to repro the scenario and demonstrate that as expected, the codebase was Deadlock City and the mysterious 1 minute "performance issues" were in fact caused by 60.0 second timeouts as I had guessed.
When I walked away from that two storey building full of "professional" developers, I had a wide-eyed look on my face wondering why literally nobody in the entire database team was even aware of the existence of the database profiler tool... which was in their Start menu the whole time.
No, that's not all that Casey did. I mean, perhaps from a very reductionist point of view it is, yes, but there's a thousand ways to implement "array lookups, 2D images and a hashtable" that are less efficient than the way that Casey did it (and probably most would be less efficient than the MS team as well...) Do you know the ins and outs of Direct2D in order to write all that out efficiently? I certainly don't.
Casey demonstrated... and it ought to be obvious... that the "ins-and-outs" of Direct2D don't matter.
If you actually bother to cache the glyphs into sprites, then Direct2D can be absurdly slow (it isn't) and still get something like 1000 fps.
Your comment is almost a parody of what went down.
How can you not see that generating a 16x20 pixel image can't possibly be the bottleneck on a modern PC unless you're doing something spectacularly wrong!?
I don't know what this means. Casey clearly uses Direct2D in his repo. If he were to demonstrate that Direct2D doesn't matter, he shouldn't have used it.
> Your comment is almost a parody of what went down.
There are thousands of programmers out there who haven't built a terminal as fast as RefTerm, and then there's Casey Muratori. If a hundred more Refterms show up tomorrow, I'll happily change my mind. Heck, you can even prove me wrong by coding one up yourself, if you'd like!
Many of us discovered around the age or 13 or 14 that POKE #B8000 plus a little arithmetic was significantly faster than using OS calls to write text to the screen. We were wrapping those in functions, inlining ASM, and building text-mode UIs as teenagers - not as long-time professionals, not college grads, and without all the information available on the modern internet.
Over the next few years, as graphical stuff became more common, we were trying different algorithms to optimize polygon fills, mouse drivers, custom fonts, etc. That was a part-time hobby for teenagers. Did not require greybeard gurus with lifetime achievement awards and college degrees and the entire internet of information always available.
It was just the basics, the fundamentals, a few decades ago.
>c:\copy con FILE.txt
F6
Oh I remember that!
He even got lectured by some expert nitwits at MS which were making dozens of arguments about how it was allegedly impossible to create a fast terminal (on modern machines, most of them with GPUs in the TFLOPS range, LOL).
I have no idea why those "engineers" weren't fired on the spot.
With all the telemetry going on in the background, Windows is worse every day. I tried Windows 11 and was amazed at how it completely nullified having a top-tier mobile i7 paired with 32GB RAM.
Take a look at how much a modern install of Windows is thrashing your drive. It's scanning everything, all the time.
In this way, users have nowhere to hide. Any refuge from the new UI changes will be tracked, identified and targeted for termination.
I extremely rarely use the software I write as intended. I am just running it against tests.
Assuming scanning 44,000 files instead of 4 takes ~11000x longer.
There is no market for a photoshop competitor with half the features but runs faster for example. Because every tool is already tuned to be just fast enough that customers are satisfied.
I’m not paid for a good user experience. My manager is happiest when features ship quickly.
Because it seems like this is a major and obvious flaw that is relatively easy to fix in a lot of different ways… yet it shipped.
It’s easy to just say that Microsft’s developers are incompetent/dumb/etc but this is low hanging fruit, and makes me think the problem is something else.
There is, in fact, a new sound recorder app on W11: https://www.pcmag.com/news/first-look-windows-11s-new-sound-....
Voice Recorder is pretty old, it got a big revamp/renaming ("Sound Recorder") in Windows 11. Problems might be fixed now?
The native development story on Windows is in shambles. UWP and WinRT have a ton of baggage but there isn't a great replacement for them yet. Many bundled apps were written in UWP when it seemed like it was the future, and now they're in an awkward not-quite-unmaintained place.
I see the trace is spending a lot of time in the Windows.Storage.* namespace and... there be dragons. Filesystem access from UWP apps is awful, it has several usability and performance shortcomings. Would not surprise me if that's a platform issue and not a Voice Recorder issue.
At the very least, this isn’t hugely useful, and if it was, why can’t it rely on a OS level file search cache to help it?
This is – besides all those programming related oddities – a question of holistic UX: if collecting the list takes that long, make the list on-demand, hide it behind a button or documents icon – and already your app is responsive for the majority of use cases and users.
Why does a voice recorder program need to list files?
That's what a file browser is for.
Jesus, is this why modern devs are completely ignorant as to how to use filesystems?
All users should understand files, in terms of how to locate them, what it means to open them, what it means to close them. They need to know how to navigate filesystems.
That's basic OS use. Kernel independent. OS independent. Hell, that's basic information retrieval system use.
Being "Task oriented" warranting blurring lines to the point you have "Sound Recorders" doing directory operations is a signal something has gone horribly, horribly wrong.
"Task oriented" is an excuse for making closed proprietary solutions that don't interoperate.
It's the reason for Steve Job's tyranny back in the day imo.
Compare the Snap version of something to a non-container version, and see how much quicker it is.
I remember easily playing half a dozen video files simultaneously, butter smooth, with the system still being instantly responsive as if it was doing nothing. On a 200mhz 603e. Those were the good old days.
Let's categorize performance into 4 poorly-defined groups: perfectly optimized, highly optimized, reasonably optimized, poorly optimized
Everyone expects you to do the reasonable thing. I mean no disrespect, but finding examples of poor optimization does not justify elitist attitudes when most developers are just being reasonable otherwise. We all agree poorly optimized code is bad and never justified. I hope we all agree that anyone is capable of at least optimizing beyond what is reasonable. Anyone who has slaved over it knows this is not a skill to be proud of. We should all wish this aspect be automated (much of it has been). If a business case is ever made to optimize beyond what is considered reasonable, then you'll get to perform your hobby for pay. Does anyone seriously believe any products are perfect?
Bonus words: To address the complaints about web dev, get familiar with the waterfall diagram in the network tab of your browser's dev tools and behold where almost all the time goes. Stop embarrassing yourself complaining about javascript. What you will typically find is slow backend responses, poorly organized backend APIs that demand a long series chain of requests to get what the page needs, huge unoptimized images, and yes ads. Blaming slow web pages on anything but the organization as a whole that produced it is naive.
Poor optimization is trivial to avoid even without "proper analytics" or "proper QA". Code won't merely feel fast if it's reasonably optimized. Taking shortcuts around slow code is harder work than just never letting it be slow in the first place. Your team's level of experience may vary, hence what "reasonable" means.
I'd also replace "developers don't know" with "project managers don't know", but if you work for a small business that distinction may not exist.
Programmers can't tell when they're making slow programs because their computers make up for it.
About a year ago, I was (sidenote, still am) looking to get a new computer. In my free time, I do game dev, so I wanted something powerful enough to give me some flexibility in that, but also weak enough that Im not making my game on a machine 10x more powerful than most people will play it on. Of course you test on other machines as well, but I believe poor optimisation should be seen as a bug, not just something to improve on. I've explained it badly, but hopefully you get what I mean. Anyway, I opened a reddit thread about this on r/gamedev, and got swamped by the old "premature optimisation..." rule.
Its not the first, or last, time I've seen this happen. And of course, premature optimisation can ruin or stall a project, but refusing any and all possible optimisation steps prior to it being a problem seems really odd to me.
If you're fiddling with getting a rarely used subsystem to load in 50ms instead of 60ms that's premature.
Imagine your developing a game on your high end PC, you run it and it runs at like 10 fps. Clearly something is wrong, thats a bug that needs to be fixed before you do anything else.
Now imagine it runs fine on your high end PC, but in testing, it runs at 10 fps.
The issues are the same, and should be treated the same, but in reality they rarely are. The testing issue would certainly be addressed, but not quite with the same urgency.
I guess that we stopped caring about performance in software a while ago...
[1]: https://apogliaghi.com/2022/09/software-midlife-crisis/
1 ftp://ftp.cs.toronto.edu/doc/programming/cnews.{ps,pdf}
The incentive for creating a user's program has become an incentive to complete quarterly assessments.
But it wasn't a simple piece of software, either. This sound recorder is.
And I'll let an expert chime in here, but I think we're many orders of magnitude faster now, on the hardware side.
Whenever you have to wait for things on modern computers, you’ve essentially been robbed.
IF everything is in the cache, there is no dependency on I/O, and cycles aren't wasted with context switching between usermode->kernel.
Unless your program is purely computational it's going to burn cycles on system calls and I/O.
And almost all of the network traffic and syscalls can be mitigated almost all of the time. Eg by caching, buffered IO, cutting out bloat, minifying javascript, static rendering, using lower res assets, and so on.
There’s exceptions - AI, video games, rendering and simulations work can take real time.
But other than that, modern computers should boot instantly, and apps should open instantly. Webpages should open within about 3x the server round trip time. There is very little software I’ve ever worked with that, with some effort, couldn’t be massively optimized.
In this case I can believe the machines this program was tested on at MS had a lot less than 44'000 files. Should they have known to test with more files? I wouldn't have.
To ensure quality, Microsoft also need to make bug reporting easy and effective. But unfortunately that's a herculean task with so many users. I'm guessing most actual bug fixes are a result of big companies with support contracts complaining. And how many of those are going to know or care about the microphone app?
Software is slow because it's not devs who make it all by themselves it's now a team and often team members are ambivalent or ignorant of performance. Requirements come first then perf later when often requirements and perf are the same.
Example you can't have a page that shows 100 million pieces of data (a requirement) and be fast. You have to pagination, lazy load ...etc. Those are requirements just as much as the fact you are showing 100 million bits of data.
Good teams have non-tech people that understand this. Bad teams (most teams tbh) don't and so insane slow shit gets put out to customers.
If you write a voice recorder for example, you _already_ know that the first thing you will do is scan the directories. Do this during start-up, let the user know that the system is initializing and then for the most part you only need to check your assertions are still true just before recording.
In general I think we need to make people care about performance more. The only thing I can think of is to make running on low-end hardware part of the validation process.
> { packageMgr } install { randomPkg }
> npm install node-plus
import { readFile } from 'node:fs/promise'
import { dirname, join } from 'node:path'
import additionChecker from 'add-check'
// redundant useless comments
return function(n1, n2) {
// redundant useless comments
n1 + n2
}In these cases it's not a matter of not understanding the low level internals.
Long time ago, in Windows for Workgroups 3.11 times, when I opened Explorer, it was getting slower and slower. Finally, changing a directory took 5 secs. The hard disk was working hard (there were LED indicators!).
I've figured out that the root cause was my C:\Documents directory, which contained a bunch of files, maybe some hundreds of mp3s, don't remember. Moved _all_ files from C:\Documents made Explorer lightning fast.
I think, Explorer wanted to show a summary of different file types, which was completely unnecessary and couldn't turnded off.
Another problem is that performance often given lower priority in enterprisey software development. For example, i'm currently working on a project where two componenens share data through a message bus. The architects decided that all messages on this bus have to use json with a bunch of headers. For my project, it could literally be 50x faster with very little effort if we could use a more efficient format, but it is not allowed.
What a weird way of thinking, I wouldn't hire anyone who says something like this. 20 seconds to load up or do just about anything on a computer is bad, regardless of some round about reasoning of ratios. I find these days there is something wrong with most developers' brains. Like we need to start a new parallel software industry and make sure no unreasonable people can be part of it.
But anyone complaining that modern Electron/Web apps have bad performance is naive. Of _course_ they do, and yes we should try to improve performance, but much of the industry as a whole has decided that features > performance for the most part.
There's a bit more info about it on page 709 of Windows Internals 7th Edition (Part 1).
And then you have hundreds of failed attempts to solve that problem which don't actually strike at the root problem, further making a mess of the computing environment so that it requires multiple gigabytes of resident memory to write and execute "hello world."
This particular app is slow because nobody cared. Not many people record voice on PCs anymore, and the ones they do, they use professional software. People just use phones for simple tasks.
Over time, someone had the idea to add search for files, they implemented the shortest hack that worked, and they left it in, because nobody prioritized this app.
Notes recording on phone is snappy and working, because people record on phones.
So, why are apps slow? Because they don’t need to be fast unless users will not use them otherwise.
Making better/faster/more reliable software is possible and I think this is an opportunity that will only reach its full potential at some point in the future, when hardware improvements will be slow enough for this effort to be competitive.
Second, the “antivirus law”: IO is considered free if it’s on a background thread. Never mind that it bogs down the computer.
What's Windows' problem? It has no excuse. Maybe, just maybe, the Windows Explorer, plus the stack it runs on, is utter garbage.
How is this a "cargo-cult"?
The hardware is great. The software has officially shit itself.
Stuff like "guitar pri" lags it.
Just constant memory spikes and slow downs. PATHETIC.
That being said, in general, modern software is more bloated than ancient software because it does more...
But you look at something like Linux where obviously the Linux of 2022 is going to lag on 2002 hardware the answer is definitely that it's prettier and does more in general.
FWIW I think software is slow these days because everything seems to want/need the network to function. Software is bloated for a different reason, namely the existence of a healthy, free, high quality sea of dependencies, from which we freely use.