Choose timezone
Your profile timezone:
Powered by Indico
v3.3.2-pre
Present: Enric, Lorenzo, Enrico, Martin, Rafael, Guilherme, Xavi, Pere, Gerri, Philippe
Next meeting
Dedicated to parallelisation of RooFit.
List of Cleanups
o Thread safety: this will dramatically improve with the R/W lock, eta end of Summer. It's in the pipeline for being solved.
o Performance, also in single threaded mode
- Time spent in THashList::RecursiveRemove. This is a notification which is the part which takes time.
- Can we opt out from garbage collection?
Solution 1. : Mark the container of the object not part of the list of cleanup
Solution 2. : Don't do any cleanup: TROOT::SetMustClean(bool)
Solution 3. : Set gDirectory to nullptr. TDirectoryContext is the RAAI to be used to disable assisted memory management for a certain scope. This in is not all what can be done. The kMustCleanup bit must be flipped.
Solution 4. : (for TFiles) remove the TFile from the list of files to avoid that it is notified by the deregistration triggered by the list of cleanups.
Global ways to avoid automatic memory management:
1) RAII which disables kMustCleanup and sets gDirectory=0. downside: things like Canvases become flacky. The Canvas has the list of pointer of the things owned by it.
- By default one set the bit of the object after drawing. Here the challenge is that it's only one particular case.
- This implies an additional global set
2) Subclass with a TUnique<T>, TNonManaged which automatic sets directory and kMustCleanup bit flipped. downside: the type changes.
Questions in the document:
A. It is safe
B. It is currently unsafe (even if with ROOT::EnableThreadSafety()). With the list of cleanups protected by the RW it will.