[scapp]

I don't see the problem. For example, if something finishes in 10 minutes, it has 6 completions per hour. If a competitor finishes in 1 minute, it has 60 completions per hour. It both finishes in 1/10 of the time (time per completion) and is 10 times faster (completions in a given amount of time).

If you don't like the unit "completions per hour", consider that you don't have to drive for an hour or even go a mile to go 60 miles per hour.

[emn13]

You are of course completely correct. However, I do think numbers like these are more intuitive when people talk about duration (or latency, or time taken; depending on context) rather than speed outside of very narrow situations.

In a car, 60mph has some kind of well-known interpretation; there's an experience to that that people can at least vaguely identify. And it's also related to fairly intrinsic limits, such as legal speed limits, safety, etc.

But even in a car, people tend to care about trip-times, not speeds. And speeds are harder to work with; If you travel 30mph on your commute to work due to traffic; and 60mph on your way home - what was your average speed? Not 45.

Outside of a car and in a computation context, it's even more impractical to talk about "speed" - after all, we're usually dealing with lots of stages; and it's rather easier to simply add up latencies than it is to some reciprocal of reciprocals dance. Even if time is workload dependent, then the time-per-workload framing tends to be more helpful than the workload-per-time framing.

As a corollary, people currently talk about high refresh gaming, and will happily report how some workload went from 300fps to 400fps, without noting that this is the same frametime reduction as going from 48 to 50fps (setting aside perceptual limitations). Workload-per-time is pretty unintuitive.

[smcl]

That's actually a nice way to look at it, and helped me see why and in what cases I dislike this phraseology - I couldn't really articulate this before. So I think my issue is presenting something in time-units per action and talking about an optimisation of it as multiples of actions per time-unit faster.

I hate it a little less now :)

[mort96]

Well, speed is distance/time. For the "speed" analogy to make sense when talking about performance, we have to translate "distance" to something more abstract, let's call it "work". That means we have speed = work/time. If you have 1 unit of work (say you think of "build the whole app" as one atomic operation) which used to take 20 seconds, and now it takes 2 seconds, you went from a speed of 1/20=0.05 to a speed of 1/2=0.5, which is a 10x increase.

Hence, "it's 10x faster" is a valid way to write "it does the same work in 1/10 the time".

[smcl]

Yeah I get it - it just feels a bit clumsy to use the flipped units when summarising the optimisation. Just a personal taste thing though.

I still think "X times less than" can GTFO though - as in 10,000 is "seven times less than" 70,000 - which is the kind of thing I'm seeing more recently. That wasn't mentioned in the article though, it was maybe a bit unfair to lump them together.