7 ms·

Can modern software be snappy? (2008)

38 points by avasthe 6y ago

jacquesm 6y ago
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.
- gameswithgo 6y ago
  are you using wasm? can you?
  - jacquesm 6y ago
    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.
- PaulDavisThe1st 6y ago
  >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
  - svantana 6y ago
    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.
    - renaicirc 6y ago
      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).
      - svantana 6y ago
        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.
    - PaulDavisThe1st 6y ago
      "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!
  - jacquesm 6y ago
    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.
jdc 6y ago
cf. Dan Luu's page on computer latency: https://danluu.com/input-lag/ https://danluu.com/input-lag/
skizm 6y ago
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.
bob1029 6y ago
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.
- pjmlp 6y ago
  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-ditching-electron-react-native-uwp https://www.windowscentral.com/xbox-app-pc-gets-speed-boost-...
  - benrbray 6y ago
    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!
darkhorse13 6y ago
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.
- ben-schaaf 6y ago
  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.
  - badhombres 6y ago
    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?
    - ben-schaaf 6y ago
      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.
  - OnlyOneCannolo 6y ago
    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?
    - ben-schaaf 6y ago
      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.
quelsolaar 6y ago
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.
- PaulDavisThe1st 6y ago
  It does have quite a bit to do with slow startup, however, which was also a part of the author's complaints.
deleted 6y ago
[deleted]
pjmlp 6y ago
Depends, how much Electron instances are you running? https://mspoweruser.com/xbox-pc-app-gains-huge-performance-gains-after-abandoning-electron-framework/ https://mspoweruser.com/xbox-pc-app-gains-huge-performance-g...
sys_64738 6y ago
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.
- pbourke 6y ago
  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.

38 points by avasthe 6y ago

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.

gameswithgo 6y ago
are you using wasm? can you?
- jacquesm 6y ago
  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.
PaulDavisThe1st 6y ago
>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
- svantana 6y ago
  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.
  - renaicirc 6y ago
    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).
    - svantana 6y ago
      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.
  - PaulDavisThe1st 6y ago
    "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!
- jacquesm 6y ago
  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.

jdc 6y ago

cf. Dan Luu's page on computer latency: https://danluu.com/input-lag/ https://danluu.com/input-lag/

skizm 6y ago

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.

bob1029 6y ago

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.

pjmlp 6y ago
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-ditching-electron-react-native-uwp https://www.windowscentral.com/xbox-app-pc-gets-speed-boost-...
- benrbray 6y ago
  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!

darkhorse13 6y ago

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.

ben-schaaf 6y ago
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.
- badhombres 6y ago
  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?
  - ben-schaaf 6y ago
    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.
- OnlyOneCannolo 6y ago
  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?
  - ben-schaaf 6y ago
    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.

quelsolaar 6y ago

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.

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

deleted 6y ago

[deleted]

pjmlp 6y ago

Depends, how much Electron instances are you running? https://mspoweruser.com/xbox-pc-app-gains-huge-performance-gains-after-abandoning-electron-framework/ https://mspoweruser.com/xbox-pc-app-gains-huge-performance-g...

sys_64738 6y ago

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.

pbourke 6y ago
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.