Re: TColor problem?

From: Akira OKUMURA <oxon_at_juno.phys.s.u-tokyo.ac.jp>
Date: Tue, 17 Nov 2009 08:38:01 +0900


Hello Axel,

> How much of a problem is this for you - do you need an urgent fix or
> is it enough to know that a) we will accelerate it a lot in the
> short term and b) we (Olivier, really...) will try to come up with a
> more fundamental solution?

It is NOT urgent (at least) for me.

I often use this kind of macro to show gamma-ray count maps, a fitting result, and a 2D residual, and execute it repeatedly. I can workaround the problem by reducing the color steps and rebooting ROOT.

I suppose a fundamental solution is not trivial because I know partially how color and palette work. But if it could be fixed, it would be great.

Thank you for your help.

Regards,

OKUMURA, Akira oxon_at_juno.phys.s.u-tokyo.ac.jp Department of Physics, The University of Tokyo 7-3-1 Hongo, Bunkyo-ku, Tokyo 113-0033
TEL/FAX +81 3-5841-4173/4059
Skype : okumura.akira

On 2009/11/17, at 1:42, Axel Naumann wrote:

> Hi,
>
> Olivier and I had a look, and we understand where it comes from, but
> we don't know yet in which way to fix :-/ Here's the story:
>
> You want to draw histograms with N different palettes, in a loop.
> For each histogram you set the palette. Alas, ROOT doesn't recognize
> that the palette you set already exists, and instead allocates a new
> one. So for each palette, for each loop iteration, new colors are
> allocated.
>
> Apart from the fact that there is a fundamental inefficiency in
> TColor (for which I will send a patch to Olivier) there is also an
> issue with the whole idea of how palettes are set: we simply never
> foresaw that they would be (re-)used that way, even though it makes
> sense in your case.
>
> How much of a problem is this for you - do you need an urgent fix or
> is it enough to know that a) we will accelerate it a lot in the
> short term and b) we (Olivier, really...) will try to come up with a
> more fundamental solution?
>
> Cheers, Axel.
>
> Akira OKUMURA wrote on 11/16/2009 05:08 PM:
>> Hello Axel and Rene,
>> Thank you for your additional explanation. I'll use Rene's
>> workaround.
>> Only root.exe holds a high CPU load. Here is a copy&paste of the
>> top command on Linux.
>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>> 21955 oxon 19 0 102m 33m 16m S 86.9 0.8 0:21.86 root.exe
>> 21962 oxon 16 0 6176 1144 852 R 0.7 0.0 0:00.03 top
>> 22687 oxon 16 0 37592 1912 1056 R 0.7 0.0 0:03.24 sshd
>>> Could you send your macro instrumented with TStopwatch? Are you
>>> sure you do not print the cumulative time?
>> This is first time for me to use TStopwatch, but its count time is
>> the same as I actually experienced (I counted the execution time in
>> my head). I will attache the new macro in which I increased the
>> number of color steps from 100 to 1000 so that the problem (?)
>> becomes more visible.
>> $ root -n
>> root [0] for(int i=0; i< 10; i++){
>> end with '}', '@':abort > gROOT->ProcessLine(".x color3.C+");
>> end with '}', '@':abort > }
>> If you cannot still reproduce it, I will try installing the latest
>> ROOT on "clean" SL 4.8 and SL 5.4 (as virtual machines) tomorrow.
>> If I get the same problem, I will move to the savannah.
>> Regards,
>> OKUMURA, Akira oxon_at_juno.phys.s.u-tokyo.ac.jp
>> Department of Physics, The University of Tokyo
>> 7-3-1 Hongo, Bunkyo-ku, Tokyo 113-0033
>> TEL/FAX +81 3-5841-4173/4059
>> Skype : okumura.akira
>> On 2009/11/16, at 20:17, Axel Naumann wrote:
>>> Hi Akira,
>>>
>>> the issue with gPad is a limitation in the coordination between
>>> ROOT and CINT. ROOT tells CINT about gPad in a special way
>>> (because in fact it's not a global variable) - but it can
>>> currently only do that once gPad is != NULL. So the workaround for
>>> now is to do what Rene suggested.
>>>
>>> You said that the additional run time is caused by some processes
>>> eating a lot of CPU time. Can you tell us (with the OS's process
>>> monitors) what these processes are?
>>>
>>> Cheers, Axel.
>>>
>>> Akira OKUMURA wrote on 11/16/2009 12:04 PM:
>>>> Hello Rene,
>>>>> I cannot reproduce your timing problem with ACLIC. I see a
>>>>> constant time for each execution.
>>>> I added an instance of TStopwatch in the macro. This is the
>>>> output. I removed some warnings for TCanvas and TH2D.
>>>> root [0] .x color.C+
>>>> Real time 0:00:02, CP time 0.300
>>>> root [1] .x color.C+
>>>> Real time 0:00:03, CP time 1.100
>>>> root [2] .x color.C+
>>>> Real time 0:00:04, CP time 2.550
>>>> root [3] .x color.C+
>>>> Real time 0:00:06, CP time 4.540
>>>> root [4] .x color.C+
>>>> Real time 0:00:09, CP time 6.960
>>>> I confirmed that this problem happens on both Mac OS X and SL
>>>> 4.6. I tried 5.25.02 and the current SVN. Configure options for
>>>> Mac and SL are
>>>> $ ./configure macosx
>>>> and
>>>> $ ./configure --enable-python --enable-pythia6 --with-pythia6-
>>>> libdir=lib
>>>> respectively. Can anyone reproduce this?
>>>>> For the other problem, replace the statement
>>>>> can->cd(i+1)
>>>>> by
>>>>> gPad = can->cd(i+1);
>>>> Thanks. It works. But actually I know that TPad::cd returns the
>>>> pointer which should be gPad. I expected that TPad::cd
>>>> automatically set the gPad to the pointer to the current pad even
>>>> if I use CINT. This is also explained in the comment of TPad::cd.
>>>> http://root.cern.ch/root/html/src/TPad.cxx.html#l0kMaE
>>>> Regards,
>>>> OKUMURA, Akira oxon_at_juno.phys.s.u-tokyo.ac.jp
>>>> Department of Physics, The University of Tokyo
>>>> 7-3-1 Hongo, Bunkyo-ku, Tokyo 113-0033
>>>> TEL/FAX +81 3-5841-4173/4059
>>>> Skype : okumura.akira
>>>> On 2009/11/16, at 16:49, Rene Brun wrote:
>>>>> I cannot reproduce your timing problem with ACLIC. I see a
>>>>> constant time for each execution.
>>>>>
>>>>> For the other problem, replace the statement
>>>>> can->cd(i+1)
>>>>> by
>>>>> gPad = can->cd(i+1);
>>>>>
>>>>> Rene Brun
>>>>>
>>>>> Akira OKUMURA wrote:
>>>>>> Hello ROOTers,
>>>>>>
>>>>>> I attache a short macro which shows younger students in my lab
>>>>>> how to use different color palettes.
>>>>>>
>>>>>> When I run it using ACLiC, it works as I expected. But I have
>>>>>> two problems. I still do not know which lines cause this
>>>>>> problems.
>>>>>>
>>>>>> $ root -n
>>>>>> root [0] .x color.C+ <= runs properly
>>>>>> Info in <TUnixSystem::ACLiC>: creating shared library /Users/
>>>>>> oxon/./color_C.so
>>>>>>
>>>>>> $ root -n
>>>>>> root [0] .x color.C <= fails
>>>>>> Error: non class,struct,union object $gPad used with . or ->
>>>>>> color.C:68:
>>>>>> *** Interpreter error recovered ***
>>>>>>
>>>>>> My questions are;
>>>>>>
>>>>>> Q1. I do not know why I cannot access gPad when I use CINT.
>>>>>> What is the problem in my macro?
>>>>>>
>>>>>> Q2. The process of root.exe becomes slowly (i.e. high CPU
>>>>>> load), when I execute the macro with ACLiC many times. What is
>>>>>> the reason and how can I remove it?
>>>>>>
>>>>>> e.g. try
>>>>>> root [0] .x color.C+
>>>>>> root [1] .x color.C+
>>>>>> root [2] .x color.C+
>>>>>> root [3] .x color.C+
>>>>>> root [4] .x color.C+
>>>>>> root [5] .x color.C+
>>>>>> root [6] .x color.C+
>>>>>> .....
>>>>>>
>>>>>> I am using
>>>>>> - ROOT 5.24.00 + Mac OS X 10.5.8 (intel)
>>>>>> - ROOT 5.24.00 + SL 4.6 (64 bit)
>>>>>>
>>>>>> Thank you in advance.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> OKUMURA, Akira oxon_at_juno.phys.s.u-tokyo.ac.jp
>>>>>> Department of Physics, The University of Tokyo
>>>>>> 7-3-1 Hongo, Bunkyo-ku, Tokyo 113-0033
>>>>>> TEL/FAX +81 3-5841-4173/4059
>>>>>> Skype : okumura.akira
>>>>>
Received on Tue Nov 17 2009 - 00:38:10 CET

This archive was generated by hypermail 2.2.0 : Tue Nov 17 2009 - 05:50:04 CET