I was watching Halt and Catch Fire and in the first season the engineering team makes a great effort to meet something called the "Doherty Threshold" to keep the responsiveness of the machine so the user doesn't get frustrated and lose interest. I guess that is lost to time!
A horrific piece of UI/UX/engineering/whatever.
When apps have these kinds of interruptions all over the place, that's even worse than just having them at startup.
Office suites have never been good, but office suites in like 2005 seemed to stretch systems to the breaking point.
Lots of consumer software has always sucked out of the box, I guess if you are here you were possibly a technically savvy kid at some point, is it possible that you were just more selective about the types of programs you ran when you were using the computer for fun?
Old days: Cmd + f, type what you want.
New days: first scroll to the end of the page so that all the contents are actually loaded. Cmd + f, type what you want.
Is just a list of dishes, some with small thumbnails, some without any images at all. If you can't load a page with 30 dishes fast enough, you have a serious problem (you could always lazily load the thumbnails if you want to cheat).
Only to discover that 2/3 of the matches are invisible text that's put there for $deity knows what reason, and the rest only gives you the subset of what you want, as the UI truncates the list of ingredients/toppings and you need to click or hover over it to see it in full.
Then again, I guess any other OS might break in same way. Like my Debian VM just kinda stops responding to part of the screen sometimes if programs are maximised...
But the real solution is better web page design.
Ruby on Rails may not be the poster child for speediness as things get big or complex, but if you aren't fighting the ORM, it's consistently quick from click to data.
Also, RoR is definitely not dead.
Actually much worse as Microsoft once did with their COM model, ActiveX based on MFC foundation classes with C++ templates, etc.
And to build those interactive programs somebody is trained to use React, Vue, etc. using their own eco systems of tools. This is operated by a stack of build tools, a stack of distribution tools, kubernetes for hosting and AWS for managing that whole damn thing.
Oh - and do not talk even about Dependency Management, Monitoring, Microservices, Authorization and so on...
But I really wonder - what would be more complex?
Building interactive programs based on HTML or Logo (if anybody does remember)?
As a bonus, in Firefox if you hit the ' key (apostrophe) you get a search that looks only within hyperlinks and ignores all the un-clickable plain text. Give it a try, sometimes it can be very useful
That depends on your scale. If your product is "large enough" it is relatively easy to get into the range of several seconds of response time.
Here are some of the steps you may want to execute before responding a resquest to your user:
- Get all the dishes that have the filters the user selected
- Remove all dishes from restaurants that doen't delivery in the user location
- Remove all dishes from restaurants that aren't open right now
- Get all discount campaigns for the user and apply its effects for every dish
- Reorder the dish list based on the history of the user interactions
Now imagine that for every step in this list you have, at least, a single team of developers. Add some legacy requirements and a little bit of tech debt... That's it, now you have the perfect stage for a request that takes 5-10 seconds.
What really drives me mad is the latency of some file selection dialogs for example which can take like 10 seconds.
I mean maybe your DB is a single node running on a potato and your load's very high but you're also somehow never hitting cache, but otherwise... no, there's no good reason for that to be slow.
[EDIT] Your last paragraph is the reason, though: it's made extremely poorly. That'll do it.
I still have this instinctual reluctance to change screen resolution in a game's setting screen, even though 99% of the time it's an instantaneous thing these days.
But it was different...
Yeah. It was. That's exactly my point.
A major problem is the number of places in our code stacks where developers think it's perfectly normal for things to take 50ms or 500ms that aren't. I am not a performance maniac but I'm always keeping a mental budget in my head for how long things should take, and if something that should be 50us takes 50ms I generally at some point dig in and figure out why. If you don't even realize that something should be snappy you'll never dig into why your accidentally quadratic code is as slow as it is.
Another one I think is ever-increasingly to blame is the much celebrated PHP-esque "fully isolated page", where a given request is generated and then everything is thrown away. It was always a performance disaster, but when you go from 1 request to dozens for the simplest page render it becomes extra catastrophic. A lot of my web sites are a lot faster than my fellow developers expect simply because I reject that as a model for page generation. Things are a lot faster if you're only serving what was actually requested and not starting everything up from scratch.
Relatedly, developers really underestimate precomputation, which is very relevant to your point. Your hypothetical page layout is slow because you waited until the user actually clicked "menu" to start generating all that. Why did you do that? You should have computed that all at login time and have it stored right at your fingertips, because it is a reasonable assumption given the sort of page you're talking about that if the user logged in, they are there to make an order, not to look at their credit card settings. Even if it expensive for reasons out of your control (location API, for instance) if you already did the work you can serve the user instantly.
Having precomputed all this data, you might as well shove it all down to the client and let them manipulate it there with zero further network requests. A menu is a trivial amount of information.
It isn't even like precomputation is hard. It's the same code, just running at a different time.
"But what about when that doesn't work?" Well, you do something else. You've got a huge list of options. I haven't even scratched the surface. This isn't a treatise on how to speed up every conceivable website, this is a cri de coeur to stop making excuses for not even trying, and just try a little.
And it is SO MUCH FUN. Those of you who don't try you have no idea what you are missing out on. It is completely normal on a code base no one has ever profiled before to find a 50ms process and improve it to 50us with just a handful of lines tweaked. It is completely normal to examine a DB query taking 3 seconds and find that with a single ALTER TABLE ADD INDEX cut that down to 2us. This is the most fun I have at work. Give it a try. It's addictive!
I have fond memories of that, but basically the editor was a UI into a linked list with a blue screen. So not comparable to what people are being asked to do with Word and 365 today.
My personal beef with Word is that it struggles so much with long documents. Trying to read, say, a 300 page spec from 3GPP is miserable.
Also that threshold is an entire 400ms. We should expect significantly better than that these days.
Also, if you work on a website, the Google crawler seems to allocate a certain amount of wall time (not just CPU time) to crawling your page. If you can get your pages to respond extremely quickly, more of your pages will be indexed, and you're going to match for more keywords. So if for some reason people aren't convinced that speed is an important feature for users wanting to use your site, maybe SEO benefits will help make the case.
There is speed, then there is the perception of speed. Crystal got this right.
But, more generally, the problem is that tech stacks are an awful amalgamation of uncountable pieces which, taken by themselves, "don't add much overhead". But when you add them all together, you end up with a terribly laggy affair; see the other commenter's description of a web page with 30 dishes taking forever to load.
I don't dispute that very bad javascript can cause problems, but I don't think it's the virtualization layers or the specific language that are responsible for more than a sliver of that in the vast majority of use cases.
And the pile of build and distribution tools shouldn't hurt the user at all.
I was using a SAST program that used MS SQL Server and was generating reports, and often finding the reports took HOURS to generate, even when the report was only ~50 pages. A report on one specific project took over a DAY to generate a report. I thought it was ludicrous, so I logged onto the SQL server to investigate and found that one query was taking 99% of the time. This query was searching through a table with tens of millions of rows, but not indexed on the specific rows it was checking against, and many variations of the query were being used to generate the report. I added the index (Only took about an hour, IIRC), and what took hours now took a couple minutes.
I was always surprised the software didn't create that index to begin with.
If you have a dozen layers and they each add 5% slowdown, okay that makes a CPU half as fast. That amount of slowdown is nothing for UI responsiveness. A modern core clocked at 300MHz would blow the pants off the 600MHz core that's responding instantly in the video, and then it would clock 10x higher when you turn off the artificial limiter. Those slight slowdowns of layered abstractions are not the real problem.
(Edit: And note that's not for a dozen layers total but for a dozen additional layers on top of what the NT code had.)
I think this is the key.
People fall in love with simple systems which solves a problem. Being totally in honey moon they want to use those systems for additional use cases. So they build stuff around it, atop of it, abstract the original system to allow growth for more complexity.
Then the system becomes too complex, so people might come up with a new idea. So they create a new simple system just to fix a part of the whole stack and allow migration from the old one. The party starts all over again.
But it's like hard drive fragmentation - at some point there are so many layers that it's basically impossible to recombine layers again. Everybody fears complexity already built.
There's also Dtrace https://learn.microsoft.com/en-us/windows-hardware/drivers/d...
Except...there's no model of precisely how text is handled or how to re-encode it for e.g. screen reading...the development model lacks the abstraction to do layout...and so on. So we added a longer pipeline with more things to configure, over and over.
But - the computing environment is also different now. We can say, "aha, but OCR exists, GPT exists" and pursue a completely different way of presenting many of those features, where you leverage a higher grade of computing power to make the architectural line between the presentation layer and the database extremely short and weighted towards "user in control of their data and presentation". That still takes engineering and design, but the order of magnitude goes down, allowing complexity to bottleneck elsewhere.
That's the kind of conceptual leap computing has made a few times over history - at first the idea of having the computer itself compile your program from a textual form to machine instructions ("auto-coding") was novel and complex. Nowadays we expect our compilers to make coffee for us.
If you get bad performance in a game nowadays it's a good idea to try proper fullscreen. Alt tabbing might be slow, but the game will run better.
For me, I use google so often that I can rapidly parse information without really needing to read much of the text, the link just sort of 'looks' right. I've observed my wife reading google results and she is much slower and more methodical, probably because she doesn't google things 20+ times a day every day like I do.
That's how I end up misclicking, because i'm not working at the speed of a normal googler.
It is really annoying though, there are some css tweaks you can make using browser extensions to make that disappear if you're so inclined.
On one project, I actually shifted quite recently from working on old-school, pre-Windows XP, DCOM-based protocols, to interfacing with REST APIs. Let me tell you this: compared to OpenAPI tooling, DCOM is a paradise.
I have no first clue how anyone does anything with OpenAPI. Just about every tool I tried to turn OpenAPI specs into C or C++ code, or documentation, is horribly broken. And this isn't me "holding it wrong" - in each case, I found GitHub issues about those same failures, submitted months or years ago, and still open, on supposedly widely-used and actively maintained projects...
Unfortunately I cannot think of a single thing that has gotten better about Spotify since I started using it, and a lot which has gotten worse.
Another one that can be slow with file dialogs is that sometimes (maybe it has been fixed now) it will try to query whether a networked drive is around on another computer. If it isn't then the call to it can be blocking your file UI.
A third problem I've noticed with file selection dialogs and explorer is that the My Computer 'folder' that contains your disks takes a long time to load. Much longer than any sub-folders on any of the drives.
I think the problem is largely with explorer.exe. If I browse those folders in a web browser the experience is snappy.
The only exceptions are: 1) the actual build, which is faster on the modern machine, but only for a large number of source files and 2) reading and writing files - a floppy disk cannot beat an nvme drive of course.
These are things we're unlikely to get back (and by themselves already make typical PC stacks unable to deliver smooth hand-writing experience - Microsoft Research had a good demo some time ago, showing that you need to get to single-digit milliseconds on the round-trip between touch event and display update, for it to feel like manipulating a physical thing vs. having it attached to your finger on a rubber band). Win2K on a hardware from that era is going to remain snappier than modern computers for that reason alone. But that only underscores the need to make the userspace software part leaner.
--
[0] - Source: I'll need to find that blog that's regularly on HN, whose author did measurements on this.
It's common enough that there were a couple browser proposals to deal with this and would address the Ctrl+F issue. I believe this has been merged into the CSS Containment spec, but at the moment it doesn't make windowing obsolete in every situation.
> Building interactive programs based on HTML or Logo (if anybody does remember)?
Hold my beer: my Github Actions CI scripts use Logo to generate the bash build scripts as images that are then OCRed and executed by a special terminal that exploits the Turing complete nature of Typescript's type system.
Turtles all the way down!
Also impressive how our brain is sensitive to all of this.. no matter how impressive a current OS / web browser / jitted js is.. I dearly miss the past eras "behavior".
That was about five years ago. :/
I have a 2015 MacBook Air I abandoned recently for being so painfully slow to use that I had almost not touched it for months. I have an iPad Air 2 that is basically unusable at this point. Both are 2-3 orders of magnitudes faster than those old computers that work instantly.
But windows and web apps are super slow now too
Think of all the landfills and wasted work hours earning the money needed to fill those landfills. The heavy and rare metals
This is proof that if computers were 10x faster, they would run slower than ours today, because in the past we’ve seen that be true over and over. The software companies will just make heavier and heavier programs and operating systems until we have gained nothing but a significant amount of co2 emissions
Not at all what I expected from a news site. They're usually full of crap and dog slow.
This is the specific URL I experienced this with. Though the whole site seems mostly very quick. https://www.bbc.com/news/live/world-us-canada-65967464
And this is on a 2017 MBP, which some sites are really slow. Nothing crazy like the new silicon CPUs here either.
If you activate the start menu with a keypress it's going to grab focus. Before it grabs focus the previous window in focus will get events. The same applies with panels (drawers? I forget Windows' name for them) in the Start Menu. There's a non-zero time between activation and grabbing focus to receive keypress events.
Everything from animation delays to stupid enumeration bugs can affect a windows not grabbing focus to receive keypress events. Scripting a UI always has challenges with timing like this.
A mainframe terminal has a single input context. You can fire off a bunch of events quickly because there's no real opportunity for another process (on that terminal) to grab focus and receive those events.
Note the above doesn't absolve Windows of any stupid performance/UX problems with bad animation timings and general shittiness. Microsoft has been focusing on delivering ads and returning telemetry with Windows instead of fixing UX and performance issues.
Experimental behavior manipulation, without even telling the subject they are part of a manipulation experiment? You would be chased out of the room and your reputation destroyed! Utterly unacceptable. But in webdev universe this is somehow seen as a totally normal practice.
Then head to the Newswaffle link and input https://bbc.com or just scroll down the page to head to the converted site.
What’s Microsoft’s excuse? Tired of their incompetence being handwaved and a several decades old jank non-solution being held up as acceptable. MS needs more accountability in their teams.
Give it some time for the industry to finally mature.
I like websockets for the same reason. Each message has a two byte overhead compared to TCP. Two bytes. Unfortunately messages sent by the client have a whopping four additional bytes to help protect buggy middleboxes.
It's extremely fast. Super duper fast. And a quick look at the network debugging tab shows why: it loads the shop's entire catalog data (about 3 megs) upfront, and the entire application runs locally with not a single request until you buy something. Now that's efficiency.
Really. Go to their website, clock on KATALOG and click some random buttons, pick a product at random, add it to your cart, remove it from your cart.
The product images are the only things that aren't pre-loaded.
According to an external wall clock the keypress events happen at seconds 1, 2, and 3. The first press triggers a window to appear (menu panels are a type of window). It takes 0.5s to instantiate and register to receive keypress events from the shell. Wall clock time is 1.5s. Nice.
The second window (menu panel) receives a keypress event at wall clock 2s which opens a third panel. That panel because it has more complicated drawing and page faulted so had to fetch a page from disk swap unfortunately took 1.2s to register for focus. A keypress triggered at wall clock time of 3s. Our third panel though didn't register focus until wall clock 3.2s. That keypress went to panel 2 because that had focus when the keypress event triggered. All times greatly exaggerated.
The shell needs to add events to processes' event queues but it can't just arbitrarily add them to every process. It also can't know any individual window wants events until the process tells it so. Unlike mouse events a keypress event doesn't have coordinates so a process can't really figure out the intended target of an event.
A model that prevents preemption means your back to the Win16 cooperative multitasking. A process can't be interrupted until it gives up the CPU willingly. That however means background processes can't do work while a foreground process holds the CPU. If you make just your shell and GUI apps cooperative the responsiveness of the system will end up awful.
What is worse than that: not being able to predict if inputs will be buffered or dropped during unresponsiveness. I kind of look like an idiot when I keep clicking/typing away on someone else’s computer while things are frozen, thinking “oh, it’ll catch up in a bit”, and then 5 seconds later I have to work harder to fix the chaos: some keystrokes at the beginning made it through, then only every other one, then the next couple hundred got dropped, but the next 100 came through fine, and interspersed everywhere there are bizarre runs of duplicated keys, as if I had held the letter aaaaaaaaaaaaaa down continuously.
Everyone’s mix of hardware, OS, text editor, text editor plugins, etc makes this behavior highly variable, and hard to guess if it makes sense to keep typing or just wait out the frequent 1-5 second lockups.
1GB programs are rarely instant but that's usually just the price for very complex functionality if it's too interconnected to load parts of it on demand.
At one point back in school a friend said to me "hey, I can't figure out how to install and boot JVM on Virtual Box. I need to use it for homework in another class. Help me?"
I wish I had been able to explain it as succinctly as you. Instead I sat there laughing in the guy's face for a good minute, eventually realizing from his expression that he was being serious, which only made me laugh even harder.
Seeing as they were posting the backlash on Reddit, I'm guessing a lot of people downloaded the app to log in and Reddit said "Big Success!" when they checked the stats.
In such an OS the APIs would allow you to atomically transfer focus as part of other operations, for example, starting a new program or opening a new window could simply transfer focus atomically to the pending new program/window such that the OS buffers keystrokes until the recipient is ready to receive them. Also, taking focus would require you to advertise what keys you're willing to receive, allowing a focus cascade such that there's never any situation in which keystrokes get delivered to a UI that isn't able to do anything with them. At the top level of the shell there'd be a kind of global command line or palette that is the default receiver of all other unhandled keystrokes. Because focus transfer is always deterministic under this scheme, people can learn where keystrokes will go without timing playing a part.
The GDPR's notion of informed consent really needs to be applied pervasively to all kinds of consumer contracts. If it's hidden in walls of text that the average user doesn't read it shouldn't count as consent.
This isn't an argument for not trying though.
This is not an inherent limitation of CPUs but a part of Windows' exclusive fullscreen concept. Just another thing that was simply accepted as the way things are instead of being improved (until exclusive fullscreen went out of style).
In my use case, impact on inserts was not noticed. I did notice higher disk space usage, but it absolutely was worth it. Spending $200 on a larger disk was absolutely worth saving literally days on report generation.
I'm quite impressed of both .NET and OpenJDK in some metrics, but it is often not resource efficient, which is something I do value.
One example of an application that works as I would expect others to do is MuPDF, Being able to open 20MB+ PDFs in 1/10 seconds on a 10 years+ old laptop.
By the way, does anyone know why Debian launches LibreOffice so much quicker than Ubuntu, Fedora or Archlinux (or any other distro I've tested with)? In Debian its 1-2 seconds, and the others 5-10 seconds. I mean it could be included extensions or how they are configured, but I'm honestly interested.
I am interested in your fast loading techniques in general. I also am considering making a bunch of personal / pro websites where I'll use a static generator. Just looking for some inspiration and ideas to steal I suppose.
Since it's kinda fresh pursuit for me, I am still looking to gather some links and do proper research. I wasn't looking to deanonymize you, my apologies.
As far as my inspiration, I use Craigslist and google as my inspiration. I try to get a sleek and simple look like google pages, but maintain the “old school” functionality and layout ideas of Craigslist .
As far as actual development is concerned, I use oracle ARM servers that are grossly overpowered for a webhost, cloudflare nameservers OR CDN, and I keep as much of the development as possible server side with as little JavaScript as I can. An example was a simple blogging system I made. The entire system is set up with a MariaDB table that has “title, date, image url, and content” as the data bits for it, and then each function works on one of two pages: a backend using php session that has all of the functions with get request, and a front end that has all of its content on a page with post requests. There is no JavaScript involved on either page, which means the stuff transmitted over the internet is lesser, the stuff done on the client computer is lesser, and the number of outside calls is lesser. This does make it “less responsive”, but does the blog really need image zoom in on hover and shit like that?
I have found the best way to develop for speed and simplicity is to curb the enthusiasm of the client from “looks as good as possible” to “simple, cheap, fast, and robust, while still looking better than average”
The final suggestion I have is to develop with security AND accessibility in mind first. If you want to put aria links of all of your stuff, it is much harder to go back later and 1) determine what the link does, and 2) write an aria for it than it is to just include it in the first place. Always follow proper form for mitigating risks like SQL injection and XSS, and do as much as possible on the server before you resort to JS.
If you are looking for a couple of sites that I didn’t build, but get the point of what I am trying to do across, check out
Smashingmagazine.com Hacker news doesn’t look the best, but it follows the logic set forth, Openai.com (this one surprised me because if you remove a lot of the slightly more interactive elements it is fast as hell)
If you have any specific questions, ask away and I’ll do my best
Figma contributes by enabling UI designers to easily author interfaces which look allegedly beautiful but are complex to build, test and maintain.
And the resources burned on building such esthetically pleasant piles of barely usable software could find better use on making it simpler, faster and more focused on user actual functional and non-functional requirements (much of them taking place on the server-side) instead of sugaring their eyes by throwing tons of code on their clients
And it seem to be the start up process that differs, as putting them all in a ram-disk does not alleviate the issue, and restarting the app cuts the time in ~1/2 but equally for each distro.
My guess, as I said first is what default libraries as loaded, and possibly how they are configured. I do however find it strange that this has not been mentioned elsewhere as I've been struck bu this difference for years, when I happen to load a pure Debian install (not what I usually use).
There was a time when a virtual function call was a lot of overhead
Even having a VMT is overhead.
Sometimes the COM interface is implemented as actual interface, where the implementing class is derived from another class and the interface. (in C++ the interface is just another class with multiple inheritance, but other languages have designed interfaces). Then the class even needs to have two VMTs.
Multiple VMTs have even more overhead. And with multiple VMTs, it is not just a method call. In the functions, this always points to the first VMT. But when a function from the VMT is called, the pointer points to that VMT. So the compiler creates a wrapper function, that adjusts this and calls the actual function.
when methods from the later VMTs are called , this points (non-virtual thunk)