Help with a really simple percentage question.

[FP]

Let's say I have a file that is 635Mb and I am able to reduce it to 470Mb with a compression algorithm. This is a 26% reduction in size right? In other words it is 1.35 times smaller right?

Ok, now let's say I have a process that runs in 3.5 seconds before a tweak and 6.7 seconds after a tweak. The tweak caused a 91% decrease in performance or stated differently caused the process to run 1.91 times longer right?

I need sleep.

EDIT: Figured it out. I was looking at it from the wrong perspective. The prefile size is 1.35 times larger than the postfile size which stated differently the postfile size is .26 times smaller than the prefile size.

I think my process runtime numbers are correct though.

 

[Epic Fail]

the 91% decrease is wrong.

 

[DaveSimmons]

A 91% decrease would mean it is only running at 9% ( = * 0.09 = 9/100 ) of its old speed.

If it ran at half of its old speed ( = 0.50 = 50/100 = 1/2 ) how much longer would it run?

Can you figure out the pattern?

 

[jagec]

Yes, a 26% reduction in size. 470 is 74% of 635. 635 is 135% of 470 (or "35% bigger", to make things confusing)

The tweak caused a 91% increase in run time (1.91 x longer to run). You have to invert that get "performance", AKA (calculations)/sec. So the "performance" of the original was 1 (unit work)/3.5 (sec) = .286,
The "performance" of the second was 1/6.7 = .149

So the latter performance was 52.1% of the former, or a 47.9% decrease.

/edit: Fixed, I'm a moron. In my defense, I'm a little tipsy.

 

[DaveSimmons]

Originally posted by: jagec
The tweak caused a 91% increase in run time (1.91 x longer to run), which according to most definitions of performance would indeed be a 91% decrease.

Perhaps we're in different fields, but I'd expect a 50% "decrease in performance" to cause a 100% increase in run time.

 

[FP]

Originally posted by: DaveSimmons

Originally posted by: jagec
The tweak caused a 91% increase in run time (1.91 x longer to run), which according to most definitions of performance would indeed be a 91% decrease.

Perhaps we're in different fields, but I'd expect a 50% "decrease in performance" to cause a 100% increase in run time.

Ha, maybe this isn't as obvious as I thought.

So if I told you my process runs in 10 seconds prepatch and experiences a 50% decrease in performance postpatch you would tell me the postpatch runtime is 20 seconds? See I would think it meant the postpatch runtime is 15 seconds.

 

[jagec]

Originally posted by: binister

Originally posted by: DaveSimmons

Originally posted by: jagec
The tweak caused a 91% increase in run time (1.91 x longer to run), which according to most definitions of performance would indeed be a 91% decrease.

Perhaps we're in different fields, but I'd expect a 50% "decrease in performance" to cause a 100% increase in run time.

Ha, maybe this isn't as obvious as I thought.

So if I told you my process runs in 10 seconds prepatch and experiences a 50% decrease in performance postpatch you would tell me the postpatch runtime is 20 seconds? See I would think it meant the postpatch runtime is 15 seconds.

No, he's right. A 100% decrease in performance means that the runtime is infinite. A 50% decrease in performance doubles the runtime. Performance is basically (1/runtime).

If you want to talk about runtime, you can use 50%, 100%, 3000% decreases or increases, but performance scales from 0% (no performance, infinite runtimes) to 100% (full performance), to above that if you're OCing or optimizing. >100% performance = more optimized routine, or a new processing system.

 

[FP]

Originally posted by: jagec

Originally posted by: binister

Originally posted by: DaveSimmons

Originally posted by: jagec
The tweak caused a 91% increase in run time (1.91 x longer to run), which according to most definitions of performance would indeed be a 91% decrease.

Perhaps we're in different fields, but I'd expect a 50% "decrease in performance" to cause a 100% increase in run time.

Ha, maybe this isn't as obvious as I thought.

So if I told you my process runs in 10 seconds prepatch and experiences a 50% decrease in performance postpatch you would tell me the postpatch runtime is 20 seconds? See I would think it meant the postpatch runtime is 15 seconds.

No, he's right. A 100% decrease in performance means that the runtime is infinite. A 50% decrease in performance doubles the runtime. Performance is basically (1/runtime).

So if I told you a process experiences a 100% increase in runtime postpatch what % decrease in performance is that?

 

[Epic Fail]

Originally posted by: binister

Originally posted by: jagec

Originally posted by: binister

Originally posted by: DaveSimmons

Originally posted by: jagec
The tweak caused a 91% increase in run time (1.91 x longer to run), which according to most definitions of performance would indeed be a 91% decrease.

Perhaps we're in different fields, but I'd expect a 50% "decrease in performance" to cause a 100% increase in run time.

Ha, maybe this isn't as obvious as I thought.

So if I told you my process runs in 10 seconds prepatch and experiences a 50% decrease in performance postpatch you would tell me the postpatch runtime is 20 seconds? See I would think it meant the postpatch runtime is 15 seconds.

No, he's right. A 100% decrease in performance means that the runtime is infinite. A 50% decrease in performance doubles the runtime. Performance is basically (1/runtime).

So if I told you a process experiences a 100% increase in runtime postpatch what % decrease in performance is that?

50%

 

[Schfifty Five]

This thread hurts my brain. lol.