RE: [ROOT] Performance question: Updating a colz histogram

From: Valeri Fine (fine@bnl.gov)
Date: Tue Oct 01 2002 - 02:52:08 MEST


Hello Ed,

Thank you very much for the working example you sent me. 
It made things much simpler to investigate.
Sorry for some delay.
I have investigated your code.

> you able to duplicate the problem I was having (e.g. cpu time required
to
> redraw scatter plot grows as histogram gets more entries)? 

Yes I did.

However your observation is not correct. It does grow but by the point. 
Your 2D histogram is 500 x 500 bins = 250 000 bins.
Just try to define 50 x 50 to see what I am speaking about.
If you will define 100 x 100 you will realize the refresh time is
growing but it quickly becomes constant. 
In fact the refresh time of 2D histogram should be proportional (at
least) to the number of non-zero cells of your 2D histogram. Since the
number of your non-zero cells is growing that refresh rate is going
down.
 
I think the better performance can be provided via
TVirtualX::DrawCellArray.
However ROOT doesn't use it. This means each non-zero bin is drawn with
several dedicated calls to the low level graphics layer. That must slow
things down significantly.  Each bin is drawn as colored box. This means
to draw it the program has to set the current color pen and color brush
and then draw the filled box. To accomplish this it needs to call the
TVirtualX layer several times. To make things ever worse the low level
layer is called via 2 other intermediate layers.


See: 
http://root.cern.ch/root/htmldoc/src/THistPainter.cxx.html#THistPainter:
PaintColorLevels 

In you case to refresh the picture ROOT calls up to 250'000 times:

         fH->SetFillColor(gStyle->GetColorPalette(theColor));
         fH->TAttFill::Modify();
         gPad->PaintBox(xlow, ylow, xup, yup);

You can see the algorithm of the THistPainter works well if the
occupancy of the cells is not high because it skips the empty cells. It
must degrade as soon as the occupancy of the cells grows (that's your
case)

> > Is there something I could do to speed things up, short of adjusting
the
> > refresh rate?  I am using version 3.03/08 on Win32.  Thanks...

At this point it would be reasonable to see whether you can use
TVirtualX::DrawCellArray methods. That will do everything in a single
call.
Be this reason one may expect the refresh time will be steady. 
However this approach requires the custom THistPainter::PaintColorLevels

method to be introduced. 

> Note 2: In addition to the 2D histogram, I also have a couple
> of 1-D histograms. [The object to display/update is selected
> at runtime.  All objects are filled all the time] The 1D
> histograms updating never slows down, only the 2D histograms

  As I have explained the time to re-draw the histogram depends of the
number of the bins to be drawn,
  Your 1D histogram contains 600 bins. This is nothing against of
250'000 bins of your 2D histogram.

   Hope this helps. My best regards, Valeri

  

> -----Original Message-----
> From: Ed Oltman [mailto:eoltman@imago.com]
> Sent: Tuesday, September 03, 2002 9:35 AM
> To: fine@bnl.gov; 'Roottalk@Pcroot. Cern. Ch'
> Subject: RE: [ROOT] Performance question: Updating a colz histogram
> 
> Valeri,
>  Here are some more details (not in order asked)
> 
> 2. I had the same problem in V 3.02/7 as well as 3.03/8
> 
> 4. I am using a standalone root based application - e.g. I
>    create an instance of TRint.  The application is an MFC
>    SDI application where I took special pains to wrap the
>    root stuff in its own class that does not have #include
>    "stdafx.h" or any other windows/mfc stuff.
> 
> 1. My application's view class has an OnTimer() method
>    which in turn calls p2DH->Draw("colz") and
>    gPad->GetCanvas()->Update().
> 
> 3. If you like, I could make a small mfc project that
>    displays the problem I'm having.
> 
> Note: you mention in subsequent e-mail that it is not
> necessary to call the Draw() method each time.  If I do
> not call the Draw() method each time, nothing gets displayed.
> 
> Note: The histogram is filled in a different thread than
> it is displayed.  I use a win32 semaphore to protect the
> object's filling with its display.
> 
> Note 2: In addition to the 2D histogram, I also have a couple
> of 1-D histograms. [The object to display/update is seleceted
> at runtime.  All objects are filled all the time] The 1D
> histograms updating never slows down, only the 2D histograms
> 
> Ed Oltman
> 
> > -----Original Message-----
> > From: Valeri Fine [mailto:fine@bnl.gov]
> > Sent: Friday, August 30, 2002 5:31 PM
> > To: 'Ed Oltman'; 'Roottalk@Pcroot. Cern. Ch'
> > Subject: RE: [ROOT] Performance question: Updating a colz histogram
> >
> >
> > Hello Ed,
> >  Sorry, you didn't send an example to reproduce your troubles so I
have
> > to ask you some extra questions:
> >
> >    1. What kind of timer do you use: synch or asynch ?
> >    2. Did you see this problem before (with the previous version of
> > ROOT) ?
> >    3. Can you work out a small macro / code to reproduce the problem
?
> >    4. Do you use "ROOT + macro"; "Root + your custom DLL"; your
> > ROOT-based application alone ?
> >
> >   Thank you
> >               Valeri
> >
> > -----Original Message-----
> > From: owner-roottalk@pcroot.cern.ch
> > [mailto:owner-roottalk@pcroot.cern.ch] On Behalf Of Ed Oltman
> > Sent: Friday, August 30, 2002 5:35 PM
> > To: Roottalk@Pcroot. Cern. Ch
> > Subject: [ROOT] Performance question: Updating a colz histogram
> >
> > Hello,
> >  I have an online application which includes a 500x500 bin TH2F
which I
> > display in response to a timer with
> >
> >     p2DH->Draw("colz");
> >     gPad->GetCanvas()->Update();
> >
> > (I've previously called gStyle->SetPalette(1,0))  Early on, when the
> > histogram is still young, the refresh is pretty quick - refreshing
at 2
> > Hz
> > uses a small amount (<10%) of the cpu time. Gradually, as the
histogram
> > fills, the refresh time increases - by the time the histogram has a
few
> > hundred thousand entries, (maximum bin contents is in the 10s) the
cpu
> > time
> > is 80% and climing.
> >
> >
> > Ed Oltman
> >
> >
> >
> >
> >



This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:51:12 MET