9 ms·

I don't know the details, but many embedded interfaces/controllers don't have very fast processors/microcontrollers and UI is really expensive compared to every

I don't know the details, but many embedded interfaces/controllers don't have very fast processors/microcontrollers and UI is really expensive compared to everything else it has to do (take some inputs, and submit some data). Think about how laggy the raspberry pi 2 or even 3 in the desktop interface. Sure they can be optimized etc, but now imagine what they wouldn've used 10+ years ago and how slow it would be. EDIT: I have to agree with you guys, even given the tech they had they should've put a higher priority on responsiveness. I don't know what the status is today, but I know even the 2015 Prius's touch screen feels too unresponsive to my liking.

jblow 7y ago
The Amiga 500 was pretty responsive, and its CPU power was epsilon compared to a Raspberry Pi or any modern embedded system. It's just that modern software is garbage. That's all.
- arendtio 7y ago
  I agree. A few years ago, I powered up some old 166 MHz Windows 95 PC and was surprised how fast it was (certainly not on all tasks, but in general).
- renox 7y ago
  And Amiga had no memory protection which means that it would be very unsafe to use Internet with it. That said BeOS was quite responsive and had memory protection, but still inadequate security for modern security attacks.
  - bmurphy1976 7y ago
    The memory protection doesn't account for the performance hit. It's all the layers of shitty software and garbage devices on top.
    - renox 7y ago
      Memory protection only adds a small performance hit that's true but it also requires a totally different way of working. I don't know much about Amiga but I remember that when reading about Synthesis (a very fast & low latency kernel https://en.wikipedia.org/wiki/Self-modifying_code#Synthesis https://en.wikipedia.org/wiki/Self-modifying_code#Synthesis ) thinking that it was only possible without memory protection..
ambicapter 7y ago
Don't think it really matters, if your device can display a dropdown, then it can display an empty dropdown and load entries within a couple seconds.
- arendtio 7y ago
  I use a Progressive Web App on a Samsung Galaxy S3 smartphone (1GB RAM) on a regular basis. If the phone just got a fresh ROM, rebooted within the last hour and the app is a fresh installation, I have no performance issues what-so-ever (~60 FPS animations, etc.). But over time things degrade. I don't know why, but every year or so I have to format the internal SD card to keep the OS in shape. If I install too many apps which run in the background the RAM gets crowded and everything starts lagging. And finally, the app itself is not as optimized as it should be, so that when I use it with the data I enter during a year or so, there are some steps which take a few seconds (rendering a list with >300 items/DOM nodes). By the way, a 'couple of seconds' is unacceptable from a UX perspective. So this is just one example where you can have a 100% good experience but also a very degraded experience with the same hardware and software, due to different factors (from OS degradation to awful O(n) optimization).
dahart 7y ago
Respectfully, that is a common and tempting argument, but no, no, and no. The raspberry pi 3 has a freaking dual core 64-bit 1.4Ghz processor that is more than fast enough to run full-screen video games at 60Hz. It's more than just an "optimization" that is making UIs on these plenty-fast processors so slow, it's a large scale failure of software engineering, building slow layers on top of slow layers. The processor is not the reason for slowness, and we've had absolutely responsive UIs not just 10 years ago, but 50 years ago too. The actual reason is economic: cheap engineering. Using freely available components not well suited to embedded devices, writing layers using scripting languages because it's easy, treating the problem as solved when the functionality is there without regard to the speed.
- tcxgy 7y ago
  > Respectfully, that is a common and tempting argument, but no, no, and no. The raspberry pi 3 has a freaking dual core 64-bit 1.4Ghz processor that is more than fast enough to run full-screen video games at 60Hz. Windows XP on a Pentium 4 was snappier than Windows 10 is on an i7 today.
- Faark 7y ago
  On the other hand, the times were the CPU was polling keyboard resistances and then directly controlling your CRT's electron beam accordingly are long over. Today's systems are complicated, and we try to hide that complexity behind abstractions. All of those with buffers. Input buffers, OS message buffers, tripple image buffers, and so on. All of it adding time. Yes, we won't again have the responsiveness we had 30 years ago. Because the tradeoffs are just not worth it. At the same time, stories like the article are a necessary reminder of there being worth in performance.
  - dahart 7y ago
    There's unnecessary complexity and abstractions -- especially in poorly designed systems, yes, that's part of my point, so I agree there. > we won't again have the responsiveness we had 30 years ago. Not sure I can agree with that. For the best systems, we absolutely have better responsiveness now than we've ever had, shorter latencies now in the hundreds sometimes thousands of hertz, and orders of magnitude more compute we can put in between input and response. Maybe the worst systems are getting worse, but I think on the whole responsiveness has been monotonically improving since the invention of the microchip. > the times were the CPU was polling keyboard resistances and then directly controlling your CRT's electron beam accordingly are long over. I don't know every system ever made, but I don't think there was any long period of time when application software on digital computers controlled the electron beam in a CRT directly or polled keyboard resistances directly, those were abstracted by the hardware via DACs & buffers more or less from the start. Maybe some of the old vector display video games did, I'm not certain, but in any case, it's been abstracted that way for more than 30 years. The first framebuffers happened almost 70 years ago, before 1950.
yoz-y 7y ago
Many systems have historically prioritized how nice they look at the expense of speed. First Mac OS X releases were notoriously sluggish for example. I cringe every time I see a laggy but 'nice' looking interface. I'd rather see a wireframe with just text, it will still be more useful than a button I can never trust.
ben509 7y ago
Given the clueless remarks I see that are invariably followed by, "I work on embedded systems," I suspect there's more bad engineering to blame than deficient hardware.
Diederich 7y ago
In 1995-1997, I wrote and maintained an application that was used, during every surgery, in critical ways in every operating room in a large, regional hospital. This app ran on a regular computer running normal Microsoft Windows 95. It wasn't terribly complicated, but it also wasn't simple. It accessed a database over the wired network for most everything it cared about doing. It took some thought and care, but it wasn't impossibly difficult to ensure that the app was always highly responsive. I think it comes down to priorities. I worked closely with the doctors who were actually using this app on a day to day basis, and working with an app that didn't slow them down was quite important for them.
wmf 7y ago
many embedded interfaces/controllers don't have very fast processors/microcontrollers I'm reminded of the discussion the other day about military procurement ignoring software. Prototype the UI first, then choose a processor that's fast enough.

jblow 7y ago

The Amiga 500 was pretty responsive, and its CPU power was epsilon compared to a Raspberry Pi or any modern embedded system. It's just that modern software is garbage. That's all.

arendtio 7y ago
I agree. A few years ago, I powered up some old 166 MHz Windows 95 PC and was surprised how fast it was (certainly not on all tasks, but in general).
renox 7y ago
And Amiga had no memory protection which means that it would be very unsafe to use Internet with it. That said BeOS was quite responsive and had memory protection, but still inadequate security for modern security attacks.
- bmurphy1976 7y ago
  The memory protection doesn't account for the performance hit. It's all the layers of shitty software and garbage devices on top.
  - renox 7y ago
    Memory protection only adds a small performance hit that's true but it also requires a totally different way of working. I don't know much about Amiga but I remember that when reading about Synthesis (a very fast & low latency kernel https://en.wikipedia.org/wiki/Self-modifying_code#Synthesis https://en.wikipedia.org/wiki/Self-modifying_code#Synthesis ) thinking that it was only possible without memory protection..

ambicapter 7y ago

Don't think it really matters, if your device can display a dropdown, then it can display an empty dropdown and load entries within a couple seconds.

arendtio 7y ago
I use a Progressive Web App on a Samsung Galaxy S3 smartphone (1GB RAM) on a regular basis. If the phone just got a fresh ROM, rebooted within the last hour and the app is a fresh installation, I have no performance issues what-so-ever (~60 FPS animations, etc.). But over time things degrade. I don't know why, but every year or so I have to format the internal SD card to keep the OS in shape. If I install too many apps which run in the background the RAM gets crowded and everything starts lagging. And finally, the app itself is not as optimized as it should be, so that when I use it with the data I enter during a year or so, there are some steps which take a few seconds (rendering a list with >300 items/DOM nodes). By the way, a 'couple of seconds' is unacceptable from a UX perspective. So this is just one example where you can have a 100% good experience but also a very degraded experience with the same hardware and software, due to different factors (from OS degradation to awful O(n) optimization).

dahart 7y ago

Respectfully, that is a common and tempting argument, but no, no, and no. The raspberry pi 3 has a freaking dual core 64-bit 1.4Ghz processor that is more than fast enough to run full-screen video games at 60Hz. It's more than just an "optimization" that is making UIs on these plenty-fast processors so slow, it's a large scale failure of software engineering, building slow layers on top of slow layers. The processor is not the reason for slowness, and we've had absolutely responsive UIs not just 10 years ago, but 50 years ago too. The actual reason is economic: cheap engineering. Using freely available components not well suited to embedded devices, writing layers using scripting languages because it's easy, treating the problem as solved when the functionality is there without regard to the speed.

tcxgy 7y ago
> Respectfully, that is a common and tempting argument, but no, no, and no. The raspberry pi 3 has a freaking dual core 64-bit 1.4Ghz processor that is more than fast enough to run full-screen video games at 60Hz. Windows XP on a Pentium 4 was snappier than Windows 10 is on an i7 today.
Faark 7y ago
On the other hand, the times were the CPU was polling keyboard resistances and then directly controlling your CRT's electron beam accordingly are long over. Today's systems are complicated, and we try to hide that complexity behind abstractions. All of those with buffers. Input buffers, OS message buffers, tripple image buffers, and so on. All of it adding time. Yes, we won't again have the responsiveness we had 30 years ago. Because the tradeoffs are just not worth it. At the same time, stories like the article are a necessary reminder of there being worth in performance.
- dahart 7y ago
  There's unnecessary complexity and abstractions -- especially in poorly designed systems, yes, that's part of my point, so I agree there. > we won't again have the responsiveness we had 30 years ago. Not sure I can agree with that. For the best systems, we absolutely have better responsiveness now than we've ever had, shorter latencies now in the hundreds sometimes thousands of hertz, and orders of magnitude more compute we can put in between input and response. Maybe the worst systems are getting worse, but I think on the whole responsiveness has been monotonically improving since the invention of the microchip. > the times were the CPU was polling keyboard resistances and then directly controlling your CRT's electron beam accordingly are long over. I don't know every system ever made, but I don't think there was any long period of time when application software on digital computers controlled the electron beam in a CRT directly or polled keyboard resistances directly, those were abstracted by the hardware via DACs & buffers more or less from the start. Maybe some of the old vector display video games did, I'm not certain, but in any case, it's been abstracted that way for more than 30 years. The first framebuffers happened almost 70 years ago, before 1950.

yoz-y 7y ago

Many systems have historically prioritized how nice they look at the expense of speed. First Mac OS X releases were notoriously sluggish for example. I cringe every time I see a laggy but 'nice' looking interface. I'd rather see a wireframe with just text, it will still be more useful than a button I can never trust.

ben509 7y ago

Given the clueless remarks I see that are invariably followed by, "I work on embedded systems," I suspect there's more bad engineering to blame than deficient hardware.

Diederich 7y ago

In 1995-1997, I wrote and maintained an application that was used, during every surgery, in critical ways in every operating room in a large, regional hospital. This app ran on a regular computer running normal Microsoft Windows 95. It wasn't terribly complicated, but it also wasn't simple. It accessed a database over the wired network for most everything it cared about doing. It took some thought and care, but it wasn't impossibly difficult to ensure that the app was always highly responsive. I think it comes down to priorities. I worked closely with the doctors who were actually using this app on a day to day basis, and working with an app that didn't slow them down was quite important for them.

wmf 7y ago

many embedded interfaces/controllers don't have very fast processors/microcontrollers I'm reminded of the discussion the other day about military procurement ignoring software. Prototype the UI first, then choose a processor that's fast enough.