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

21–30 of 272 posts

Re: Slow Software

#21

Post by Aeolun »

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…

But to be fair, plain Jira can be pretty fast, it’s just when you get into an enterprise environment and people think they need 2000 different fields things fall apart.

Re: Slow Software

#22

Post by Aeolun »

jblow wrote: post #17
chrisweekly wrote: post #8

Earlier quoted context omitted.

is 'judder' a synonym for 'jank'?

‘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.

Re: Slow Software

#23

Post by [deleted] »

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…

[deleted]

Re: Slow Software

#24

Post by Skunkleton »

Aeolun wrote: post #21
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…

But to be fair, plain Jira can be pretty fast, it’s just when you get into an enterprise environment and people think they need 2000 different fields things fall apart.

Why shouldn't 2000 fields be fast? Shouldn't all of what jira does boil down to straight forward SQL queries?

Re: Slow Software

#26

Post by singlow »

beefsack wrote: post #11
chrisweekly wrote: post #8

Earlier quoted context omitted.

is 'judder' a synonym for 'jank'?

No, "judder" is like a shaking or vibrating, "jank" just means bad quality.

Jank has a more specialized meaning here, related to delays in UI rendering that cause frames to be dropped intermittently which reduces the smoothness of motion.

Judder is a perceived vibration or motion aliasing caused by the incoherence of consecutive frames at a fixed sample rate.

Re: Slow Software

#27

Post by Skunkleton »

merb wrote: post #6
gleenn wrote: post #2

I like how the site is an example of very fast software, such a simple design and it renders immediately; a single file load with the tiniest of javascript to make the videos work. A full page load in 27ms with only 14kb transferred!

to be fair the site is a html site only and gets served via cloudflare. not a fair metric against a "dynamic" site. also most webservers/frameworks/whatever will favor throughput over latency.

This site is fast, why should I care how it got fast?

Re: Slow Software

#28

Post by microcolonel »

gleenn wrote: post #2

I like how the site is an example of very fast software, such a simple design and it renders immediately; a single file load with the tiniest of javascript to make the videos work. A full page load in 27ms with only 14kb transferred!

Though, if I were to critique it, I would say that the JS was not really necessary for such a simple case for video. There's only one (I guess H.264 is considered ubiquitous now) and the big central play button just gets in the way of the video (and on most platforms, the default styling of the element puts a big play button over top of it anyway).

Re: Slow Software

#29

Post by coder543 »

Aeolun wrote: post #21
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…

But to be fair, plain Jira can be pretty fast, it’s just when you get into an enterprise environment and people think they need 2000 different fields things fall apart.

I've never seen JIRA be "pretty fast", so I can't agree. I also think "2000 different fields" is an unfair exaggeration, if we're going to focus on being fair. The 10 to 20 fields that people might use per issue should not prevent JIRA from being fast with the right architecture.

Re: Slow Software

#30

Post by tyingq »

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…

The cheap androids aren't so shabby these days. A Moto G5 play is a quad core 1.4GHz with 2GB of ram. No speed demon, but is reasonable. $109.99 on Amazon, unlocked.
Post reply on HN