Can modern software be snappy? (2008) | Hacker News Reader

Can modern software be snappy? (2008)

blog.brush.co.nz

38 pointsavasthe39 comments

I feel that many times my source of fatigue can be traced back to my tools being laggy pieces of shit for no good reason.

I don't understand what prevents actors like Microsoft from doing a clean, lightweight, native rewrite of tools like Visual Studio for people who are looking forward into the .NET 5 horizon, and don't care about being able to debug VB.NET apps written in 2009. There is no reason there has to be any delay at all in the UI. Graceful degradation of intellisense is acceptable depending on project complexity, but there should never be any sort of perceptible hitching or delays when moving code windows around, scrolling, typing, switching tabs, minimizing/maximizing, etc. If my PC can display the complex 3d scenes of Overwatch at 2560x1440p@180FPS with <5ms input latency, I cannot comprehend any rational argument for my IDE being unable to achieve even 10% of that performance objective.

I understand that use of frameworks like ElectronJS make it virtually impossible to achieve my stated objectives, so perhaps we need to dust off some APIs and re-learn old tricks. Think about the aggregate developer hours that could be saved with 1 heroic implementation effort. Imagine if you could load a VS solution in less than a second and immediately start clicking through the UI in any direction without any fear that it is about to sandbag your ass with frustratingly-arbitrary UI delay soup. That is the kind of UX that inspires confidence and encourages a developer to charge forth, instead of compelling them to fuck off on HN for the 20th time of the day.

I can understand perhaps avoiding rewriting complex applications, but why are core components like the search, taskbar, and the settings app so dog slow? This stuff was new for windows 7 or 8. Still, if I type 'bluetooth' in the search bar it can take 10s to find the settings page by that name. Maybe part of the reason native apps have fallen out of favor lately is that the OS can't even provide an example of a modern performant one.

The taskbar and basic building blocks being slow is just because Microsoft doesn't give a shit anymore (and doesn't have to, given their near-monopoly). There's no good reason something that was fast in Windows 7 on a mid-range ~2009 PC is now slow as an old pig on machines orders of magnitude faster.

React Native for Windows/macOS team keeps showing performance charts where Electron has a 300x performance loss against React Native.

I keep wishing for the day that VSCode team finally replaces its engine with one based on React Native and then Electron gets its first fatal blow.

Meanwhile, https://www.windowscentral.com/xbox-app-pc-gets-speed-boost-...

>I keep wishing for the day that VSCode team finally replaces its engine with one based on React Native and then Electron gets its first fatal blow.

Which would be never, since tons of VSC functionality is based on the ability to create ad-hoc widgets (through HTML).

Ad-hoc widgets can be equally easily created in React Native.

If you mean combining a few existing ones to make a custom component and adding some style yes.

If you mean ad-hoc widgets, the kind you can create in HTML or a native UI, then no.

Yeah, because React Native is frozen in time without any extension API to plug into.

Yeah, because "extension API" != "easily" as in HTML...

It appears that there is no Linux support planned as part of the Window+Mac React Native? That would be an absolute shame, as one of the benefits of Electron is that I can run VS Code, etc. on Ubuntu.

I'd gladly jump ship from Electron as soon as there's a viable alternative, but we can't forget that it's lack of cross-platform support that got us here in the first place!

I have been writing cross platform software since 1994, there was no Electron back then.

Electron as idea of shipping a full browser alongside the application has already been born multiple times, just it got luckier this time with the amount of devs that aren't willing to actually learn anything else.

Any solutions for cross-platform text editing + rich layouts? Afaik that's where native apps really run into trouble, as solo developers don't want to spend time re-inventing the wheel. (Nor should they have to). Especially on Linux, GTK applications really fall short of the Electron alternatives.

I'm building an Electron app based around ProseMirror, but would happily jump ship if there were a suitable cross-platform native solution.

Then use Qt, or do like we use to do back in the good old days, or as many still do on mobile space, wrap everything that can be made portable in C or C++ logic, using native views on top using MVVM patterns.

Sublime Text is one those modern tools that I would call snappy. I pray that it stays that way. I tried Atom once, but every key press had tiny lag, drove me insane.

I can say with confidence that Sublime products will always have a focus on performance. We generally treat any performance issues as high priority and you can see the result of that with most updates shipping some kind of speedup. Sublime Merge 2 for instance has shipped GPU rendering which has seen massive improvements at huge resolutions like 8k. Disclaimer: I work for Sublime HQ.

1. I can say I really appreciate the fact that you guys focus so much on performance.

2. I understand that sublime is closed source and respect that, but would sublime ever release or talk about how they develop their GUI? What libraries and techniques they use?

There's a fair amount of information scattered around about how parts of our GUI toolkit work, but there may be a blog post or two about that in the future. In general though it's not a particularly novel design on the toolkit end - the basics are all pretty similar to others. We just tend to put a lot of effort into making things work well and work fast.

I've read that Sublime uses its own custom GUI toolkit. If you had to write Sublime from scratch today, do you think you'd go the same route?

I wasn't there when that decision was made, so it's hard to say, but there's good reasons we tend to re-implement stuff found in existing open source software: Designing and building our own lets us be faster for our specific use case and gives us the control to fix bugs that are performance related or otherwise. It also means we hold a full understanding of the stack in-house allowing us to fix a lot of things. The most painful bugs for us to fix usually come from things we don't have direct control over, like OpenGL drivers, system libraries, etc.

As a hypothetical example if we used GTK instead and it's rendering implementation was designed to be CPU based - say it's based on direct pixel manipulation by passing around a texture - if we wanted to be performant at high resolutions we'd have to refactor/rewrite large parts of GTK to use GPU rendering instead. That would mean either working with the maintainers to get something they'd be happy merging, then doing the work for all of gtk, or forking gtk ripping out the parts we don't use and just refactoring those. The latter would be significantly less work and the likely choice, so we'd likely end up in the same place as before.

May I ask how well you compare with Visual Studio + Visual Assist for Unreal Engine 4 projects on Windows ?

This is not just a performance question.

I've gotten beyond tired of the thousands of paper cuts with the current combo and would love to find a better solution on Windows, even if it is paid.

thanks.

Edit: Just saw it's free to try. going to download it and try out

What about a focus on a roadmap and more frequent updates?

Sure, we've got Sublime Merge 2, but hardly anything for Sublime Text in almost a year (since last September I believe).

And it's not like ST is done and perfect for eternity -- there are several issues still and lots of ways VSC has an edge for example...

You guys are a gem. Probably the best piece of software I use.

Pavel Fatin’s tests agree with you — search for “Editor latency in Windows (text file)” on this page: https://pavelfatin.com/typing-with-pleasure/

Interestingly gvim had the lowest latency in this test. I wonder if that’s a side effect of it being written largely in C (Sublime Text uses a proprietary cross-platform C++ framework).

Notepad++ is still one of if not the best and most reliable pieces of software I’ve ever used. Better than sublime IMO. VLC coming in at a close second. These two are probably the last “snappy” pieces of software I use, besides maybe terminals.

I’m sure there are others but these are the two the come to mind.

That's quite timely. I'm writing a soft real time piece of code for use in the browser. It's a nightmare. So many layers underneath that it is very hard to get any kind of idea where latency and throughput issues are coming from.

>soft real time piece of code for use in the browser

Maybe you should reconsider.

My definitions:

    * hard real time: people will die or things will be destroyed if a certain block of code is not executed within N msecs of something happening

    * soft real time: nobody will die but things only really work correctly if a certain block of code is not executed within N msecs of something happening

Why anyone would think that a web browser (equipped with whatever VM abstractions you care to name) is a suitable platform for even soft real time is completely beyond me.

I write soft real time for a living (a multiplatform DAW). We have to go to great lengths to ensure performance, and we do things that you will NEVER(1) be able to do in a browser.

(1) for any reasonable definition of NEVER

That sounds overly dramatic to me. I'm writing a DAW of sorts for the browser, and while I wouldn't use it on stage, it works well enough to produce music on. I didn't even add AudioWorklet support yet, and I will probably release without it and consider it if users complain about stutters etc.

Have you tested on a variety of platforms? In my experience, some are very good about this (e.g Chrome on macOS) and some are a common source of problems (e.g. Firefox on Linux, at least with PulseAudio).

It seems to work well on the popular platforms (chrome, safari, ios, android) although I haven't tried linux yet. Wasm performance can vary between browsers though, which will impact the experience a lot.

"DAW of sorts"

Obviously, one can do music creation and audio processing in a browser.

The parameters that matter are what N is in the "N msecs" I mentioned above, how much audio (e.g. tracks) and how much processing (i.e. DSP).

When you make N small enough, make the track count large enough, and do enough DSP, it's never going to work inside a browser (it sometimes won't work outside the browser).

If N is large enough, the track count small enough and/or there's not too much DSP going on .... have fun!

It is a MIDI application that is only useful when delivered via the web. I don't have much choice there. So yes, it is a hard path. But then again, if I can get it to work then it will be a very neat little project. So for now I'll just stoically plod through and try to eliminate each of the little gotcha's one-by-one.

But the ease with which apparent guarantees are tossed around by browser documentation (with regards to time) only to see them solidly trashed in real life is depressing.

are you using wasm? can you?

No and possibly. I definitely hold that one as a trump card of sorts, I have a few other tricks up my sleeve that I can still use.

Fast software is not the same as small executable. I don't care how many instructions an executable contain, I care about how many are needed to be executed to do what i want. There are plenty of times where a larger executable means faster execution (Loop unrolling is an obvious example).

There are plenty of reason why a lot of modern software is slow, but size of executable isn't even in the top 10.

It does have quite a bit to do with slow startup, however, which was also a part of the author's complaints.

Depends, how much Electron instances are you running?

https://mspoweruser.com/xbox-pc-app-gains-huge-performance-g...

It's cheaper to buy faster computers nowadays. Code optimization for speed and size is a lost art as the programming world is filled with layers and layers of libraries and frameworks nobody knows what happens under the covers.

Sometimes it’s not possible to buy your way out of the problem with better hardware. If the issue is locking, or inefficient data structures, or interpreter overhead then there will be a floor to your gains. That floor might be quite high, and throwing hardware $$$ at it might not lower the floor by much. Web browsers can be pigs on core i5’s and monster Threadrippers.

cf. Dan Luu's page on computer latency:

https://danluu.com/input-lag/

Reply on news.ycombinator.com