[Ovirt-devel] re: got it!

[David Lutterkort]

On Tue, 2008-07-29 at 14:30 -0400, mark wagner wrote:
> 
> Steve Linabery wrote:
> > Pursuant to my previous email with same subject line...
> > 
> > Here's a bit of follow-up information.
> > 
> > The
> >          0.upto(@pool.hosts.total_memory) { |x| 
> > 	        if x % 1024 == 0
> >             	scale.push((x / 1024).to_s) # divide by 1024 to convert to MB
> > 		    end
> >          }
> 
> Would seem to be easier and quicker to do something like the following pseudo code
> 
>     ticks =  pool.hosts.total_memory / 1024
>     0.upto(@ticks)
>     { |x|
>        scale.push(x.to_s)
>        end
>     }
> 
> Not saying its that its the correct or even the best solution, just that it
> would seem to be faster... You are going through the loop 1024 times less and
> only doing one divide ( in this case the divide probably gets turned into 10
> right shifts) instead of pool.hosts.total_memory divides and comparisons.

No, this is still wrong - you still push into scale an unbounded number
of time, and therefore need an unbounded amount of storage for it.

It makes no sense to have more than N ticks on the scale, where N is
something that might have to be determined by a little experimentation
and looking at the resulting graph but I'd think that N between 10 and
20 is more than enough.

So what you really want is something like

     # make N marks on the y-axis, every STRIDE MB, leaving about 
     # 5% space at the top
        stride = ((pool.hosts.total_memory_in_mb * 1.05) / N).to_i + 1
        scale = (0..N).collect { |y| y * stride }
        
Ideally, you'd choose the unit adaptively, i.e. whether to use MB or GB
(or PB ;), for example so that 0 < STRIDE < 100 as a unitless number,
but that requires a little more experimentation with what ultimately
looks good.
 
David