#include "TROOT.h"
#include "TFile.h"
#include "TTree.h"
#include "TBrowser.h"
#include "TH1.h"
#include "TH1F.h"
#include "TH2.h"
#include "TRandom.h"
void Analise_ROOT_I(const char* fileNameIn="crmc_eposlhc_72406074_p_p_3500.root"){
//Precision:
cout<<fixed;
cout<<setprecision(5);
// *******************************************************
// Open the file that have the object Tree
// *******************************************************
TFile *fin = new TFile(fileNameIn,"READ");
// *******************************************************
// Take the object TTree that be inside of the file .root
// *******************************************************
TTree *Particle = (TTree*)fin->Get("Particle");
// *******************************************************
//definition of variables
// *******************************************************
Double_t px, py, pz, E, m;
Int_t nPart, pdgid, status;
// *******************************************************
// Access the leaf of the TTree
// *******************************************************
Particle->SetBranchAddress("nPart",&nPart);
Particle->SetBranchAddress("pdgid",&pdgid);
Particle->SetBranchAddress("status",&status);
Particle->SetBranchAddress("px",&px);
Particle->SetBranchAddress("py",&py);
Particle->SetBranchAddress("pz",&pz);
Particle->SetBranchAddress("E",&E);
Particle->SetBranchAddress("m",&m);
//read all entries and fill the histograms
Int_t nentries = (Int_t)Particle->GetEntries();
// *******************************************************
// Create a window for show the graphic
// *******************************************************
TCanvas *c1 = new TCanvas("c1","c1",10,10,700,500);
//c1->SetFillColor(18);
c1->SetGrid(1,1);
c1->SetLogx(0); // 0 == scale without Log, 1 == scale with Log
c1->SetLogy(0);
// create one histograms
TH1F *hpx= new TH1F("hpx","px distribution",100,-3,3);
//Fill the histogram
for (Int_t i=0; i<nentries; i++) {
Particle->GetEntry(i);
hpx->Fill(px);
}
//Draw the histogram
hpx->Draw();
hpx->GetYaxis()->SetTitle("dN/dpx [GeV^{-1}]");
hpx->GetXaxis()->SetTitle("px [GeV]");
}
Error:
^Candre@andre-QBEX-H61H2-M17:~/ROOT$ root -l macro.C
root [0]
Processing Analise_ROOT_I.C...
ERROR leaf:pz, len=1069989368 and max=909
ERROR leaf:pz, len=1068155873 and max=909
ERROR leaf:pz, len=1072372272 and max=909
ERROR leaf:E, len=1078495556 and max=909
ERROR leaf:m, len=1077788337 and max=909
ERROR leaf:pz, len=1070995620 and max=909
ERROR leaf:E, len=1082607030 and max=909
...
Someone have some tip to fix this, Thanks in advanced.
… And that’s exactly why we recommend the use of TTreeReader and TDataFrame! You might want to give those a try, they make reading a TTree much simpler.
indeed.
but ROOT’s rootls has 2 major deficiencies IMHO:
hyphenation is wrong (but that’s great: I can then use the correct one for my tools :P)
it’s, like other ROOT6-linked binaries, very slow to start up (OK, rootls is a PyROOT script but still)
I’ve notice this very irritating behaviour since a few ROOT6 releases.
there seems to be some kind of cache/re-JIT-ing? effect that goes on that makes running ROOT6-linked binaries very slow to start for binaries that one hasn’t used for a while.
see:
$> time rootls -t crmc_eposlhc_72406074_p_p_3500.root > /dev/null
real 0m2.771s
user 0m0.791s
sys 0m0.185s
$> time rootls -t crmc_eposlhc_72406074_p_p_3500.root > /dev/null
real 0m0.733s
user 0m0.657s
sys 0m0.075s
compared to a completely statically linked Go binary:
$> time root-ls -t crmc_eposlhc_72406074_p_p_3500.root >/dev/null
real 0m0.005s
user 0m0.003s
sys 0m0.003s
on a day-to-day basis, it’s super irritating. (on the plus side, I can bask in the blazing-fast side of Go :P)
Sebastien, please stay reasonable. How does language matter here? Of course we could write the same 0.005s binary also in Javascript and it would be at least as relevant…
We’ll look into the slow startup, that’s of course broken - and it wasn’t like that for the last releases:
So thanks for the report! Which exact version, which platform are we talking about, how was ROOT built / configures and most importantly what kind of filesystem / hardware is ROOT being loaded from? (And shouldn’t this have gone into a separate topic, Sebastien?)
(I’ll answer here partly and will create another thread for the requested details)
First of all, I just happen to use Go, right, and I am enthusiastic about that but the interesting part here is “statically linked [compiled] binary”.
it’s just easier to produce completely statically compiled binaries in Go.
you could do the same in C or Fortran. or JavaScript+Emscripten+Rust. or just Rust. (you could also try to do the same in C++)
the language doesn’t matter here, just the mechanism by which you get the binary.
I don’t think I am being unreasonable.
I am just talking about a different implementation of the ROOT file format (that happens to be written in Go), that works at a different point in the n-dimensional phase space of all quantities that matter for the set of all possible programs and use cases in the known universe.
this implementation has pros and cons wrt the C++/ROOT implementation.
it strikes a different compromise, one that better suits my needs.
For small command-line executables that need to be executed quickly, for which loading gazillions of .so completely dwarfs the command’s runtime, it hits the sweet spot.
PS: I must say I was actually surprised to find out rootls was actually a ~1K lines PyROOT script.
I thought it was a simple C++ application (but the same slow startup behaviour does happen for my own C++ ROOT reading files benchmark applications.)
