[Ovirt-devel] re: got it!

[Steve Linabery]

On Tue, Jul 29, 2008 at 01:10:08PM -0700, David Lutterkort wrote:
> 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.

agreed.

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

hugh and I had some chat about this; for instance, we could make our graph "smart" enough to use a logarithmic scale when the data has lots of large and small values.

I think for the initial re-implementation, we'll use the maximum value in the data series + 5% as the top of the scale, and place ticks at more or less round number intervals within.

Steve