During analysis development, my standard work pattern in ROOT5 is as follows:
edit unnamed macro with lots of commands, etc.
run in root, producing results
play with calculated variables from the command line
edit macro
repeat
A key part of step #3 is that the variables generated in the unnamed macro are available in memory to manipulate quickly at the command line, which helps determine what needs to be done in step #4. Named macros don’t work in this workflow because the variables aren’t global.
At the moment, this cannot be done in ROOT6 because variables are not reset when re-running a macro. This has been discussed before:
It doesn’t seem like fixing this is a high priority, which I find quite remarkable, since it has prevented most of the people I work with from upgrading to ROOT6. Perhaps there is a better/different workflow we should be using in ROOT6? We tried exiting root after step 3 every time, but the startup delay of root is large enough to make this unacceptable.
what do you mean by slow startup (1s, 10s)? ROOT 6.10/04 boots and quits in 150ms on a machine with SSD drive.
What is the reason of the slow startup? Some code you are running perhaps?
And yes, we feel the pain. It’s terrible, and I’m keeping all the bug reports related to reloading open, to signal how important this is to the world. I am not the one managing resources, so all I can do is work as hard as I can…
A (ugly) workaround that I use sometimes on very simple unnamed macros is to always define variables in the following way:
{
n = int{5};
s = string("test");
gDirectory->Delete("myhisto");
myhisto = TH1D("myhisto","",10,0,10);
}
The first time that the macro is executed, cling intends these lines as the “command-line-only shortcut” allowing to skip auto.
Any subsequent time, it will be intended as assignment.
Of course I do not suggest it as a “production code” approach, as you could have surprises (something constructor can be different than assignment) and could include dangerous side-effects that are not immediately visible (e.g. I am not sure if the second time the previous TH1D object is not leaking… I do not know what gDirectory->Delete() is exactly doing behind the curtains…), but for some short trial&error test maybe you can survive…
On my machine (w/ SSD), 6.10/02 completes a start/stop cycle in about 400ms, which is fine for normal startup, but becomes untenable for rapid iterations on the macro. There is some startup code I use which probably accounts for half of the delay.
is the unsatisfactory judgement you formulate linked to your workflow which needs to run at a higher rate than the present one or to the latency you experience when restarting ROOT?
Not sure I parse the question properly. Basically, I want to be able to achieve the same fast cycle times that I can in root5. For instance, with 2 windows open, I can perform the following loop quickly and with a bare minimum of keystroks to iterate on the contents of macro: edit, switch window, up-arrow-enter, switch window, repeat.
The focus on loop time is probably not productive anyway. Consider that in the root5 case, I am allowed to build up any number of other (outside of macro) variables in the session (perhaps from other macros), which I can use and refer to, etc. and which don’t get lost when I rerun the macro. This obviously cannot be done if you have to exit the session each time to restart.
Anyway, thanks to the team and to Axel, who I can tell feels the pain. Hopefully the decision makers can be convinced that core functionality should trump bells and whistles like docker containers…