Slow objects destruction

TMVA
1

In my code I produce quite a lot of Roo* objects. Their creation time is fast. But when the program is about to finish and I start to release memory (delete object), I see that the destruction time is verrrry slow: it is about 10 objects per second. I use MacOS and I “sampled” the process at the moment when the objects were being deleted. Pleadee have a look to the log below. There are pretty many calls for “Find”,“Cache” which (I think) are slow. Is it a bug or feature? I know the objects which I need to remove. I definitely can do this orders of magnitude faster with a direct “delete” calls. How can I speed up the code?

“C programmers think memory management is too important to be left to the computer. Lisp programmers think memory management is too important to be left to the user.
(from Ellis and Stroustrup’s The Annotated C++ Reference Manual)”

Thanks,
Alexander.

[codeTotal number in stack (recursive counted multiple, when >=5):
47 operator delete(void*)
46 free
43 szone_free_definite_size
25 THashList::RecursiveRemove(TObject*)
25 operator delete
16 TStorage::ObjectDealloc(void*)
15 TObject::operator delete(void*)
14 TList::Remove(TObject*)
13 TList::FindLink(TObject const*, int&) const
13 TList::RecursiveRemove(TObject*)
13 TObject::~TObject()
12 TDirectory::RecursiveRemove(TObject*)
11 RooNameSet::~RooNameSet()
11 RooNormSetCache::~RooNormSetCache()
11 TListIter::Next()
11 small_free_list_add_ptr
10 RooCacheManager::~RooCacheManager()
10 RooObjCacheManager::~RooObjCacheManager()
9 RooAbsArg::~RooAbsArg()
9 RooAbsReal::~RooAbsReal()
9 RooLinkedList::Remove(TObject*)
9 RooRealVar::~RooRealVar()
8 RooAbsPdf::~RooAbsPdf()
8 TString::~TString()
7 RooLinkedList::findLink(TObject const*) const
6 RooAbsCollection::~RooAbsCollection()
6 TObject::IsEqual(TObject const*) const
5 RooAbsCollection::safeDeleteList()
5 RooAbsRealLValue::~RooAbsRealLValue()
5 RooLinkedList::Delete(char const*)
5 szone_size

Sort by top of stack, same collapsed (when >= 5):
szone_free_definite_size 889
small_free_list_add_ptr 233
RooLinkedList::findLink(TObject const*) const 196
RooHashTable::~RooHashTable() 190
RooAbsCollection::remove(RooAbsArg const&, bool, bool) 126
TFormula::ClearFormula(char const*) 110
FitFunction::~FitFunction() 109
RooAbsPdf::CacheElem::~CacheElem() 108
RooPlot::~RooPlot() 100
RooCacheManager<std::vector<double, std::allocator > >::~RooCacheManager() 96
TList::FindLink(TObject const*, int&) const 84
szone_size 48
RooCacheManager::~RooCacheManager() 31
TListIter::Next() 31
std::_Deque_iterator<RooAbsCache*, RooAbsCache*&, RooAbsCache**> std::__find<std::_Deque_iterator<RooAbsCache*, RooAbsCache*&, RooAbsCache**>, RooAbsCache*>(std::_Deque_iterator<RooAbsCache*, RooAbsCache*&, RooAbsCache**>, std::_Deque_iterator<RooAbsCache*, RooAbsCache*&, RooAbsCache**>, RooAbsCache* const&, std::random_access_iterator_tag) 26
THashList::RecursiveRemove(TObject*) 25
RooLinkedList::Delete(char const*) 14
Figure::~Figure() 11
TObject::IsEqual(TObject const*) const 9
THashTable::RemoveSlow(TObject*) 7
TObject::RecursiveRemove(TObject*) 6
RooNormSetCache::~RooNormSetCache() 5
posix_madvise 5
[/code]

2

Hi,

when trying do delete some 1000 TGraphs and TGraphErrors I also have
the problem that it is VERY slow. I’ve tried to reproduce this in an script
where I create and delete a lot of graphs, but failed… So the problem should
be in the code I’ve written. The problem is, that when looking with “Shark”,
profiling tool in Mac OS X, what I see is only “root”, see the included
screen shot.

Any ideas anyone?

root-config --version --features

5.25/01 asimage astiff bonjour builtin_afterimage builtin_ftgl builtin_freetype builtin_glew builtin_pcre builtin_zlib cint5 cintex editline exceptions fftw3 genvector ldap mathmore memstat minuit2 odbc opengl python reflex shared ssl tmva xft xml xrootd thread

uname -a
Darwin A-MacBook-Pro.local 10.3.0 Darwin Kernel Version 10.3.0: Fri Feb 26 11:58:09 PST 2010; root:xnu-1504.3.12~1/RELEASE_I386 i386

that is a Macbook PRO running 10.6.3

root comiled x86_64

cheers

Joa

3

…the attachment

:blush:

Screen shot 2010-04-17 at 7.35.05 PM.png1422×869 182 KB

4

Hi,

If it is what I think it is: feature in the sense that the interpreter and the rest of the C++ code communicate when objects go away, so as not to leave dangling pointers in the interpreter. This is for all TObject derived.

If you are sure you don’t need this feature, you can unset the kMustCleanup bit, which will prevent calling of the RecursiveRemove machinery.

Cheers,
Wim

5

Hi,

calling TH1::AddDirectory(kFALSE) before the creation of the histograms might also help.

Cheers, Axel.