[HN Gopher] X is justifiably slow (2022)
___________________________________________________________________
X is justifiably slow (2022)
Author : todsacerdoti
Score : 49 points
Date : 2024-06-01 18:23 UTC (4 hours ago)
(HTM) web link (zeux.io)
(TXT) w3m dump (zeux.io)
| danans wrote:
| At the very least, X is definitely the most overloaded product
| name in tech.
| bravetraveler wrote:
| The same way flat earth as a debate topic has been
| misappropriated, as has this - the concept of a variable
| adolph wrote:
| Pro gives X a run for its money. Xtreme iAir
| Pro+ | AI for My Blockchain
| xwowsersx wrote:
| I only realized this post wasn't about Twitter when I reached the
| end.
| pohl wrote:
| The rebranding from Twitter to X, then, has been more
| successful than anticipated. It should have been X Windows that
| one mistook the topic for.
| GaggiX wrote:
| If you know Twitter already or it's like the opposite.
| marcosdumay wrote:
| I guess people stopped associating "X11" with "slow" at some
| point in the early 00s.
| pxc wrote:
| X11 is indeed what I first thought this was about.
| amaccuish wrote:
| Is the post not deliberately ambiguous for humorous effect?
| yuliyp wrote:
| What did you think after the first two sentences?
| GeorgeTirebiter wrote:
| Me too. I'm not sure I would have clicked if the tagline
| weren't, effectively, clickbait.
| beretguy wrote:
| Nuh, elon screwed it up for everybody
| userbinator wrote:
| Me too. It makes very general points but it could apply to
| Twitter, which is IMHO what makes this so ambiguous. The fact
| that X is actually slower than I think it could be (remember
| the "light" version that didn't need JS at all?) adds to that
| ambiguity.
| neilv wrote:
| I'm just going to keep calling it Twitter.
|
| Usually, I will call people however they preferred to be
| called, even when it seems silly.
|
| But renaming Twitter to "X" crosses the line of confusing. I'm
| not sure it should've been allowed.
| asveikau wrote:
| I thought this was about X11, not twitter.
| spion wrote:
| Same. Coincidentally, wayland is pretty fast.
| wyldfire wrote:
| The site currently shows a footnote:
|
| > As should be obvious from the framing, X here is a variable,
| not a web site formerly known as Twitter.
| asveikau wrote:
| I know. I read that. I didn't say it was about twitter. I'm
| saying that many commenters, and the article itself, seem to
| think people will confuse it with twitter, but I confused it
| with X11.
| nasretdinov wrote:
| Yes, even during my career computers became faster by a factor of
| ~100 or so, yet computers don't feel much faster if at all. Yes,
| they're much more _capable_, but usually even less responsive
| than e.g. in Windows 95 days.
|
| I think just having the intuition of how fast computers can work
| is what the industry is sorely lacking. I am usually able to
| achieve very good performance for the stuff that I'm working on,
| despite the fact that it often requires a stupid amount of
| computation, just because I know how much a computer can actually
| do in a given amount of time when it's tuned correctly.
| JTyQZSnP3cQGa8B wrote:
| I can only agree to this. 500 times faster and still slower
| than Windows 3.1 for almost the same set of features.
| Semaphor wrote:
| It's hard to say after all this time, but I think I was
| frequently waiting on everything in the win 95 days, while now
| even a small delay is annoying and standing out.
|
| Pressing a key to start a launcher, typing and using enter
| within a second does not seem to have been possible back then.
| endgame wrote:
| But back in those days, you had confidence that the event
| loop didn't randomly drop things, and you could type ahead of
| what was on screen with confidence.
| arp242 wrote:
| My computer boots in about 10 seconds. That's probably about
| average? In the Windows 95 days that would have seemed almost
| impossible.
|
| Most applications and games launch in single-digit seconds. I
| don't recall this being the norm in the Windows 95 days
| either.
| dylan604 wrote:
| Just the spinning rust turning at 5400rpm seems like that
| would have been all but impossible. With modern NVMe
| devices, waiting for data to load isn't really a bottle
| neck. At 1200MBps+ speeds, we had to span 16 7200rpm drives
| in RAID-0 to get close to that speed.
|
| With all of that, it does feel wrong to have to wait for
| apps to load. How much of that is the calling home to
| validate the app has been signed?
| nasretdinov wrote:
| That's true, loading times improved drastically with SSDs.
| The responsiveness isn't just about the loading times though.
| E.g. if you're typing text some web sites (thankfully not
| this one) manage to introduce a measurable delay between a
| key press and when letters appear. Computers in Win95 era
| were quite slow to be able to do anything complicated on each
| key press, so usually there was no extra processing and thus
| no extra delay. Also, few remember, but CRTs weren't limited
| to 60 Hz, and I remember using e.g. 100 Hz normally (with
| lower resolution), and the difference was quite noticeable.
| diarrhea wrote:
| > having the intuition of how fast computers can work
|
| I wish I never developed it. It turned what used to be mild
| annoyances into questioning my career choices.
| globular-toast wrote:
| My GNU/Linux system using sway window manager feels at least as
| fast as Windows 95. I actually have been able to appreciate
| speed increases with computer upgrades. That is, until I open a
| web browser...
| mrob wrote:
| My GNU/Linux system using LXQt feels faster than I remember
| Windows 95 being. I attribute this mostly to higher refresh
| rate on the monitor, and optical switches and faster polling
| on the keyboard and mouse. Modern gaming hardware is good
| even if you don't use it for games.
| bruce511 wrote:
| I'm old enough to remember when speed was the defining factor
| for everything. Benchmarks were a critical part if selling,
| everyone knew the mhz of their cpu, speed was the most
| important thing, it was the only thing.
|
| And I'm not talking about techies, I'm talking about the man in
| the street.
|
| Today, all computers, all programs are "fast enough". Most
| people can't name a benchmark, much less use it for comparison.
| Computer sales seldom focus on mhz. Your phone is either fast
| or slow. But actual measures are not what phone users care
| about.
|
| These days it's all about capability. Most of which is assumed
| to exist as table stakes, and which didn't even exist in
| Windows 95 days.
|
| Maybe people under-estimate how fast their PC is, but equally
| they grossly underestimate how much work it -is- doing.
|
| Some, but not huge, amounts of time are spent on making things
| "as fast as they can be". Because customers are paying for more
| capability, not more speed.
| lazide wrote:
| UI latency has gotten horrendous, both desktop and web.
|
| That is what people are experiencing - 500ms-3000ms delays
| for basic UI interactions (or more), frozen UI's, jerky/laggy
| autocomplete and UI renders. Like the classic 'button is a
| different button by the time you see the old button and click
| on it'.
|
| On incredibly lightly loaded and overpowered hardware.
|
| Everyone has been focused on some core algorithm, and
| completely ignoring the user experience. IMO.
| lucasmullens wrote:
| I remember learning that you get about 100ms for a basic UI
| interaction before a user perceives it as slow. And you get
| about 1s for a "full page navigation", even if it's a SPA,
| users are a bit more understanding if you're loading
| something that feels like new page.
|
| Getting under 100ms really shouldn't be hard for most
| things. At the very least it should be easy to get the
| ripple (or whatever button animation) to trigger within the
| first 100ms.
| lazide wrote:
| Usually these issues are caused by doing work in the UI
| thread (easy, when it's 'cheap') synchronously.
|
| All UI thread frameworks end up doing the UI interactions
| on a single thread, or everything becomes impossible to
| manage, and especially if not careful, it's easy to not
| properly setup an async callout or the like with the
| correct callbacks.
|
| It is easy to make a responsive, < 100 ms UI, it's often
| harder to keep it that way.
| AgentOrange1234 wrote:
| I wonder to what degree people are actually experiencing
| this.
|
| I'm on a 5-year old intel Macbook, and I think in my daily
| experience, core software (browsers, emacs, keynote, music)
| are pretty snappy.
|
| I do routinely work with some extremely frustratingly slow
| software, but it's pretty stark how much its performance
| stands out as, well... exceptionally bad.
| ssl-3 wrote:
| UI lag is a problem, for sure -- and so are some of the
| dynamic layouts that are meant to "solve" it[1].
|
| One thing I've noticed lately is mouse lag. Like, say, in
| Ye Olde Start Menu on Windows: Move the mouse to the Start
| menu, and press the mouse button down. _Nothing happens._
| Release the button, and then: Something happens.
|
| The menu is triggered on button-up events, not button-down
| events. This adds a measurable delay to every interaction.
|
| Same with Chrome when clicking on a link: Nothing happens
| until the button is released. This adds a delay.
|
| I mean: Go ahead and try it right now. I'll wait.
|
| And sure, it might be a small delay: After all, it can't be
| more than a few milliseconds per click, right[2]? But even
| though the delay is small, it is something that is
| immediately obvious when opening the "Applications" menu in
| XFCE 4, wherein: The menu appears seemingly- _instantly_
| when the mouse button is first pushed down.
|
| [1]: It took me more than three tries to pick a streaming
| device from Plex on my phone yesterday. I'd press the
| "cast" button, and a dynamic list of candidate devices
| would show up. I'd try to select the appropriate candidate
| and before my thumb could move the fraction of an inch to
| push the button, the list had changed as more candidate
| devices were discovered -- so the wrong device was
| selected.
|
| So I then had to dismantle the stream that I'd just started
| on the wrong device, and try (and fail) again.
|
| [2]: But even small delays add up. Let's say this
| seemingly-unoptimized mouse operation costs an average of
| 3ms per click. And that 100 million people experience this
| delay, 100 times each, per day.
|
| That's nearly an entire year (347 days) of lost human time
| for the group per day, or 347 years lost per year.
|
| Which is _4.4 human lifetimes, per year_ that are lost
| within the group of 100 million, just because we 're doing
| mouse events lazily.
| teddyh wrote:
| Which, if any, GUIs have ever activated anything decisive
| on mousebutton- _down_ events? IIRC, everyone uses
| mousebutton- _up_ events as the imperative factor.
| ssl-3 wrote:
| XFCE 4 is that way for most things that I've tried right
| now: The menu panels and desktop context menus work on
| button-down.
|
| Switching Chrome tabs works on button-down. Activating
| the three-dot menu in Chrome also works on button-down
| (which is good) but then it needlessly fades from 0% to
| 100% opacity (which is a crime against nature).
|
| I didn't even have to go digging in the memory hole to
| find this. It's right here in front of me.
| teddyh wrote:
| Sure, many menus _open_ on mousebutton-down events, but
| nothing is opened or started until the mousebutton-up
| event.
| ShroudedNight wrote:
| Don't games do this all the time?
| teddyh wrote:
| I'm not sure games count as GUIs as pertaining to this
| discussion. GUIs _in_ games would qualify, sure.
| ShroudedNight wrote:
| > The menu is triggered on button-up events, not button-
| down events.
|
| I just tried this on Firefox and can confirm similar
| behaviour. Some of the things I clicked on appear to have
| some alternate long-press function despite having a
| pointer device with multiple interaction modes.
|
| It seems we have condemned our desktops to large
| latencies on the off-chance someone might try and
| interact with them using touch.
| mbreese wrote:
| The mouse event thing is a bit misleading.
|
| Mouse interactions have (at least) 5 different events:
| hover, down, up, click and double click. The interactions
| you describe all happen "onclick", which requires a down
| and up event to happen consecutively.
|
| I get your point, that small delays add up, but mouse
| events aren't a great example, IMO. Each of the events
| have a purpose and you want to make sure that a button is
| only activated with an onclick, not just an ondown.
| renegade-otter wrote:
| So this isn't just me. I thought I was getting more
| impatient, but performance does seem to be degrading as it's
| no longer considered to be a _feature_. There is absolutely
| ZERO reason why a modern operating system or some rudimentary
| site with 10K users should not be blazing fast.
|
| I have to constantly close my browser on a 12-core Intel Mac
| MINI just because four open sites get its fan spinning like
| it's a Hoover Dam turbine.
| dkarl wrote:
| When people are used to virtually everything waiting on
| multiple round-trips over cellular connections, there's no
| point in optimizing local performance. An extra hundred
| milliseconds of lag in the UI gets attributed to the
| slowness of the connection.
|
| Plus web and mobile developers have put a ton of work into
| animations and things like that to make slowness feel
| natural, which lowers expectations even further. Nobody
| expects a device to respond quickly. You expect to have to
| wait a bit for round-trips or animations or both.
| agumonkey wrote:
| When I see vintage computers (amiga, atari) boot up
| straight into a repl in an instant I have to admit I feel
| confused.
|
| Modern uses forced a lot of layers for genericity and
| security ..
| koito17 wrote:
| > Computer sales seldom focus on mhz.
|
| For good reason. Clock speed isnt the sole factor in
| performance. A PowerPC 970 can clock up to 2 GHz, but it only
| achieves 8 instructions per cycle (on average!) for
| arithmetic instructions. Modern mobile CPUs clocked at a
| fraction of 2 GHz achieve much higher throughput for
| arithmetic. The branch predictor in the PPC chip, while
| impressive for its time, is simple in comparison to those of
| modern processors. A CPU without pre-fetching is going to
| have much worse latency and throughput than any CPU with it.
| So on, so forth.
|
| Overall, it's naive at best to focus on clock speed for
| performance. I used to fixate on it when I was a teenager,
| but not anymore.
| fanf2 wrote:
| 8 instructions per cycle is a lot, especially on average! I
| checked and the PPC 970 could fetch, decode, and issue at
| most 8 ALU ops per cycle, but it could only retire 5
| instructions per cycle, so its average IPC is probably less
| than 4.
|
| https://www.anandtech.com/show/1702/2
| userbinator wrote:
| 8 RISC instructions per cycle is much easier to achieve
| than CISC ones.
| dtx1 wrote:
| Honestly we ALL know that the reason modern computing sucks is
| Javascript. And until we replace it with something
| fundamentally less awful, it'll eat every last CPU Second we
| have.
| dylan604 wrote:
| The fact that we took Javascript out of the browser and
| started to allow it to be used server side was a sad day to
| me. Like who let the patients run the sanitarium with that
| decision?
| TheAceOfHearts wrote:
| Recently I've been playing around with Dear ImGui and it's so
| fast that now all other pieces of software feel sluggish in
| comparison. It starts up near instantly and it's incredibly
| snappy. Even using Python bindings is still incredibly fast.
|
| Meanwhile I find it very challenging to build performant web
| apps without digging myself into a framework-shaped hole, even
| when the app shouldn't be doing anything particularly
| complicated.
|
| Maybe part of it is a skill issue on my end, but it really
| feels like a team of smart engineers could help bridge the
| performance gap between native and web. Or maybe create an
| island that sits in the middle.
| freeone3000 wrote:
| The performance hole is the javascript. Drop back to rendered
| HTML and some simple CSS rules for display, avoiding redraws
| and never having a single reflow, use system fonts, and host
| resources on the same domain as your HTML. You will be
| _amazed_ at the speed!
| whstl wrote:
| But pure Javascript in itself is rarely the problem,
| there's plenty of CPU-demanding websites that are
| responsive and performant.
|
| IMO the problem is what JS enables: making lots of very
| slow Ajax calls for every small interaction. Which works
| great in development machines but sucks when a real network
| is involved.
|
| But your point stands, dropping to server-rendered HTML
| makes it fast again.
| ileonichwiesz wrote:
| It's not just the Ajax, it's all the frameworks and
| libraries running on a single thread. Before your browser
| gets to the "button clicked" callback it has 10 other
| things to do first in its stack. Modern React apps can
| feel slow even when they're not making any external
| calls.
| oDot wrote:
| It's not only the language itself, but also the way it
| lends itself to the developer.
|
| I've been using Gleam in Vue[0] for my task app Netful[1]
| and it surprisingly reduced a lot of the jank, because...
| it's sync.
|
| Awaits are used very often for things that shouldn't be
| used for and have compounding overhead.
|
| [0] https://github.com/vleam/vleam
|
| [1] https://nestful.app/
| wudangmonk wrote:
| Its easy to see how people would become used to expect
| everything to be slow. Python is the most popular programming
| langauge both in schools and in general.
|
| I can't think of a slower language. Then all your IPC is done
| through json as if everything was a website hundreds or
| thousands of miles away instead of something more sensible such
| as a shared memory.
| userbinator wrote:
| Java? Its speed, or the lack thereof, was a common joke in
| the 90s and 00s.
| Yoric wrote:
| But that changed a long time ago. Now, the main bottleneck
| with Java is memory usage, but 20 years of JITing have
| turned Java into a language more than fast enough for most
| tasks.
|
| Won't beat Rust on most benchmarks, of course.
| duxup wrote:
| I dunno man, after we moved to SSDs I felt like things sped up
| dramatically.
| AndrewKemendo wrote:
| Because they got smaller at the same time as they got faster.
|
| We pretty much locked in a latency pattern (eg, acceptable
| upper bound for user path completion speed) such that we're
| happy with the speed you can go. Much faster and it feels
| weird.
|
| We just want to continue to shrink it down.
| trunc8 wrote:
| I had a Dell 333p from 1992 running Windows 3.11 via DOS 6. For
| many years I would dig it out and see it beat newer PCs from
| boot-up into editing a Word document. And Word 2.0 had a lot of
| the features I suspect most people still only use these days.
| agumonkey wrote:
| Another aspect of it is that a lot of the enhancements bought
| by insane hardware speed is not that crucial to my mind when I
| use a computer. When booting NT5 .. I realize that just a bit
| of fading or slide-in once in a while is just about right. Even
| limited UI framework, with some flicker .. doesn't bother me,
| and there's a strange feeling of being bare-metal / lean /
| primitive that felt good the last time I used it.
| threeseed wrote:
| > As should be obvious from the framing, X here is a variable,
| not a web site formerly known as Twitter
|
| This could be one of the needlessly confusing articles I've seen
| yet.
| al_borland wrote:
| Is the world going to have to agree on a new generic
| variable/placeholder name, just because of Twitter...
|
| I think X on its own should never be Twitter, it should always
| be referred to as x.com to eliminate any ambiguity.
| foobazgt wrote:
| In CS, foo, bar, and baz are those metasyntactic variables.
| marcosdumay wrote:
| > it should always be referred to as x.com
|
| I vote on "the website previously known as Twitter".
| TeMPOraL wrote:
| How about just "X Twitter", as in "ex Twitter"?
| chuckadams wrote:
| I'm tickled that "Xitter" is gaining traction. Use the
| Chinese pronunciation of X.
| nevermore24 wrote:
| Yes, I read the 30 other posts about it, too.
| poochkoishi728 wrote:
| Is X not X11? I read the article thinking it was that.
| poochkoishi728 wrote:
| > As should be obvious from the framing, X here is a variable
|
| Not only did I misunderstand the article, the author tops it
| off by calling me a dummy at the end..
| Dwedit wrote:
| Not an article about Twitter.
| Chyzwar wrote:
| It is consequences of industry moving to feature factory model.
| It takes time to learn how to improve, understand and profile
| performance. Furthermore, it is not only performance, it is
| everything. Doctors spend like 10 years learning, but there is
| expectation that a fresh bootcamp developer can build a full-
| stack application.
| tempestn wrote:
| I think this is the first time the Twitter rename has caused me
| significant confusion with an unrelated article.
| renegat0x0 wrote:
| 1)
|
| Most of web programs are slow because of ad business.
|
| You need to be evaluated. Are you a robot? Which cohort you fit
| into? Which ads should it fed you?
|
| They capture every bit of information about you, so you could be
| tracked more, or to sell your data.
|
| Then they display what you want to see.
|
| Corporations focus not on providing info you would like to see.
| Therefore X/meta/youtube will not have a good subscription UI /
| behavior.
|
| The corporations focus on suggestion algorithms so they can spoon
| feed you with data they want to monetize for advertisers.
|
| 2)
|
| Big corporate projects are built by thousands projects, and
| thousands abstractions tied together by a duct tape. Layers upon
| layers, built by engineers not happy with outcome, but engineers
| that met deadline.
| captainmuon wrote:
| I think often people don't put in the extra mile to make things
| resource efficient or snappy (they may or may not have good
| reasons not to of course).
|
| It starts with choosing the right algorithms, using an index
| instead of doing a linear search, minimizing network traffic, ...
| but sometimes there are just unneccessary sources of slowness.
|
| I was tinkering with a react-native app the other day which shows
| a map and lets the user click on a building, and then highlights
| the building and shows some information. There was a noticable
| delay after clicking which made it not much fun to use. So I
| spent a couple evenings (hobby time, not company time) to
| integrate a proper spatial database with a fast spatial index,
| precache a lot of data, so I didn't have to hit the network. It
| got snappier, I could query a lot of geometry much faster, but it
| still felt slow. Then I looked into the source of the libraries,
| and in some react-native glue code I found that the event handler
| was waiting after the first tap for a double-tap, and thus would
| only register the tap after a couple hundred ms. One tiny change
| and it became blazing fast.
|
| I believe most apps could do most things instantaneously. Google
| can find any document on the net in a few ms, after all. But of
| course not everybody has the time and money (or even skills) to
| polish their apps that much. If the customer will buy your app
| when it is good enough then why should you put in more work
| (besides from a personal sense of craftsmanship)?
| nevermore24 wrote:
| They don't know _how_ , that's the entire problem. Six months
| in a crappy boot camp doesn't teach you a single thing about
| computers qua computers. The industry has been suffering with
| mediocrity for so long, that even today's managers don't know
| what performant software looks like. But as long as people get
| paid, nobody cares. It's depressing as all hell.
| nickdothutton wrote:
| If you have time, begin with the physics. How many bits have to
| change, how many have to move, how many have to be computed? Do
| they really have to move? Do they really have to be computed? Do
| they really have to change? Do they have to change now and every
| time? Can they remain in-situ? Works on the CPU register scale,
| and on the availability region/continental/global scale. While
| modern hardware provides a wealth of capabilities WRT SIMD, multi
| threading, and of course the revolution in storage over the last
| 20 years... sometimes you can design-out a lot of the heavy
| lifting.
|
| My first program ran on a 2MHz CPU with 64KB RAM and (floppy)
| disk access time measured in seconds. I think something of the
| art and science has been lost when even a wonderful "toy"
| computer runs at 2.4GHz.
|
| Often when I ask "what is the system really doing when X is
| slow?" people (including developers who built it) have little
| idea.
| ajsnigrutin wrote:
| No matter how fast CPUs get, shitty programmers and their
| managers with enshitification strategies will make software slow
| again.
|
| What new features does windows 11 have compared to win XP? Now
| compare the requirements needed to even start the OS.
|
| Web is even worse... 2kB of usable information means tens of
| megabytes of downloaded crap, and that's even before the ads. Why
| does a simple site with a sidebar need megabytes of javascript?!
| nevermore24 wrote:
| You can only optimize at your current level of abstraction.
| Writing JavaScript? Have fun, there's a floor to your
| performance, because you're on the 28th floor of the
| abstraction skyscraper, and you can only go up. Part of the
| issue is that developers don't know any better, the other part
| is that everyone suddenly decided that four virtual machines
| crammed inside each other like a matryoshka doll is the only
| valid way to write software anymore.
___________________________________________________________________
(page generated 2024-06-01 23:00 UTC)