Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Slow Software

inkandswitch.com

Post reply on HN
Print view View original

121–130 of 272 posts

Re: Slow Software

#121

Post by lloeki »

Aeolun wrote: post #22
jblow wrote: post #17

Earlier quoted context omitted.

‘judder’ refers to dropped frames in a fixed-frame-rate application, frames that are not dropped but are rendered too late, or, more generally, variance in frame rate of a program that should be smoothly animating.

I think ‘jank’ would refer to the same thing, as soon as it lasts longer than a few frames. E.g. the program runs consistently otherwise, but somehow freezes for 0.5s every minute or so.

My intuitive interpretation has been that `jank` is related to frame dropping but with time perception being constant (like sampling being insufficient yet played at correct times) whereas `judder` also has a sort rubberbanding effect on time, where time is perceptutally compressed or dilated as playback is delayed or "catches up", with frame dropping happening upon e.g a deadline being missed. Here, with frames 2 and 4 being costly to render:

    normal: F1....F2....F3....F4....F5....F6
    jank:   F1....F2..........F4..........F6
    judder: F1....F2........F3....F4......F6

Re: Slow Software

#122

Post by PavlovsCat »

Shank wrote: post #53
PavlovsCat wrote: post #3

> Android and iOS both make substantial use of "long press" to access context menus, which require that the user wait hundreds of milliseconds in the middle of their command gestures. > A related source is delays for disambiguation. For example, on mobile Safari there's a default 350ms delay between when the user taps a link and when the browser begins fetching the new page, in order to tell the difference between a…

> I really wish mobile devices had one or two modifier buttons on the side. Look, I feel you in terms of lost functionality, but I don't when it comes to trying to explain how these systems work to my family. Android was notoriously bad because the back stack behaved totally sane to programmers, and insane to everyone else. When Android had a "menu" button on the bottom too, it was another source of confusion. "What…

> it was another source of confusion. "What does the menu button do?

How is that impossible to explain?

> I know for a fact my mom didn't even know her phone had a trackball on it (hiya Android 2.x era), but she was mystified when I told her what it was and what it did.

And? You're just saying such things are impossible to explain for you, or impossible to explain to people you know.

But consider how complex the world is. The alphabet has 26 letters, all of which are impossible to explain. We have complex books, simple books, some people even drive cars with all sorts of levers and buttons and many dozen street signs to learn. They earn instruments and raise children, all sorts of complicated stuff, but they can't learn what a button does?

How about we simplify English, remove 95% of the words, because some people never use them?

Re: Slow Software

#123

Post by stirner »

> When dragging items on the screen, for example, users perceive latencies as low as ~2ms

This seems doubtful, given that even a state-of-the-art 240Hz screen only refreshes every 4.16ms. I guess they could compare dragging on a screen to dragging a physical object, but that would still be comparing 4.16+ms latency to 0ms latency, which doesn't explain the 2ms figure.

Re: Slow Software

#124

Post by bartread »

coder543 wrote: post #5

I think this article places too much emphasis on input devices and hardware constraints, and not enough on software architecture. JIRA doesn't really feel any faster just because your input devices are fast; the application level latency dwarfs the input latency by a large margin. I would take measurements, but JIRA prohibits benchmarking for some reason... ¯\_(ツ)_/¯ they're probably just trying to save everyone else…

> I think this article places too much emphasis on input devices and hardware constraints, and not enough on software architecture.

No it does not: it clearly makes the point that due to device, hardware, OS, and framework latencies your application has very little time budget in which to respond and still feel fast to users. This will necessitate considerable effort in terms of architecture. I don't see how that's under-emphasising it.

To have a useful discussion on architecture within the article they'd have to talk about the specifics of different software and applications, which obviously vary considerably according to the requirements for said software and applications.

The danger with that sort of thing is that some people will say, "well, if we use architecture X then our application will feel fast," disregarding many of the detailed requirements of their domain that mean X won't always (or possibly even ever) perform well.

To some extent that's unavoidable but I think this article was absolutely on point in that it makes clear the constraints within which software developers must operate, and sensibly leaves architecture as the responsibility of those software developers.

Re: Slow Software

#125

Post by michaelmrose »

notduncansmith wrote: post #76
sb8244 wrote: post #61

Earlier quoted context omitted.

Is your jira heavily customized? I haven't seen this level of slowness and use it daily. I know that customizations can be the root of evil on jira

And this level of open-ended configurability is why many vendors prohibit benchmarking. While Atlassian is exceptional in some regards, this is not one of them.

If jira is slow crap when used in the way real people use it then isn't this a meaningful fact worth sharing?

Re: Slow Software

#126

Post by LolNoGenerics »

voltagex_ wrote: post #18

I keep coming back to thinking that it's the gap between dev and "mainstream" hardware. Forget about phones for the moment (lol, Javascript performance on a $99 Android). My PC is a 6-core, 32GB of RAM beast. I suspect that most (non-PC gamers) people's machines look closer to https://www.officeworks.com.au/shop/officeworks/p/acer-aspir... . Dual core, 8GB of RAM, spinning hard drive (!) I can tell you from experienc…

Windows certainly doesn't a good job to run well on lower end systems. It got fast and reliable if you hit a baseline. Still they're hardly a competition for linux if you don't care about gaming.

Hardware retailers are just grabbing cash from average users. You cannot proof how well a system is performing so you just make up numbers and fancy words. Product series merely exists to nudge prices, they guy who buys the cheapest stuff is the biggest looser.

Cosumers would be served better if they used linux on their cheap systems. You only need a browser anyway. I used an early asus Eee PC netbook for some time with ubuntu. Yes it wasn't really snappy but it was on par with what my parents used to use. But more reliable in log term and 3 times cheaper.

But like linus said, linux won't take over the desktop market unless it is widely sold with machines out of the box.

Re: Slow Software

#127

Post by alimbada »

stirner wrote: post #123

> When dragging items on the screen, for example, users perceive latencies as low as ~2ms This seems doubtful, given that even a state-of-the-art 240Hz screen only refreshes every 4.16ms. I guess they could compare dragging on a screen to dragging a physical object, but that would still be comparing 4.16+ms latency to 0ms latency, which doesn't explain the 2ms figure.

> This seems doubtful

Ever tried playing a fast paced game with VSync turned on?

Re: Slow Software

#128

Post by SmellyGeekBoy »

jccalhoun wrote: post #41

When I read the headline I thought this was going to be something like slow food or the slow movement in general https://en.wikipedia.org/wiki/Slow_movement_(culture) and arguing for software to be slower. I'm glad I was wrong.

My understanding of Slow Food is that it isn't necessarily about "slowness" so to speak. More about keeping things close to nature and not interfering with them / overprocessing too much. Something similar would make sense for software (e.g. using lower level languages, less extraneous JS on websites etc)

Re: Slow Software

#129

Post by SmellyGeekBoy »

keldaris wrote: post #110
dorukane wrote: post #86

While comparing Samsung and Apple mobile device latencies the article gives these examples: Tapping latency examples (Videos slowed 16x): - Opening a settings tab on an iPhone 6s with ~90ms of latency. - Toggling a setting a Samsung S3 with ~330ms of latency. I agree latency is evil, I hated Android a while ago because of this. Apple always felt really fast compared to other OS. BUT it seems normal that toggling a se…

Isn't that just ridiculously slow animations for the most part? I still use an ancient OnePlusX that I got when it came out and I've disabled all UI animations, toggling most settings (with legitimate exceptions like activating the wifi hotspot feature) feels almost instant, certainly nothing close to 300 ms. Admittedly, I haven't used any iPhone in many years, so I can't really compare.

> Isn't that just ridiculously slow animations for the most part?

Agreed, and as the recent example with the iPhone calculator proved, Apple aren't exactly immune to this either.

Re: Slow Software

#130

Post by badpun »

LandR wrote: post #100
Moru wrote: post #78

Earlier quoted context omitted.

This still exists with todays computers and systems? I remember back in school (a long time ago) we had computers that was so slow it took 7 seconds for the backspace key to start doing something on some of the computers. This was in the 286 age with windows 3.11 I believe. I haven't seen it much since then. What in the world are you using to have this experience?

My work laptop is an i7 with 16GB RAM and I sometimes see this delay in inputs when running Visual Studio. I type a line of code then wait a few seconds for it to appear. Weird thing is when it does this, I'm not using all the memory and the CPU is normally sitting way below 50%. I've no idea why it sometimes just gets unusably slow.

Cpu sitting below 100% indicates that the program is spending time waiting for a data fetch from disk or memory.
Post reply on HN