[PATCH] D20933: Preallocate ExplodedNode hash table

Anna Zaks via cfe-commits cfe-commits at lists.llvm.org
Fri Jun 3 18:51:06 PDT 2016


zaks.anna added a comment.

Ben,

By the way, thanks for the patch! It's a clever idea.

> The implementation of FoldingSet has a vector of bucket pointers. Reserve preallocates that vector of 

>  bucket pointers to the correct size to avoid rehashing. The allocation of the nodes themselves hasn't 

>  changed.


My point was that we are now preallocating more.

> With a value of 150,000 steps (the default?),


This is the maximum number of steps after which we just give up analysis. It's very unlikely that the analyzer will execute this many steps on average. Moreover, this number can be reset from command line.

I would prefer not to use the same constant here. We should use another constant. Maybe, we could determine the default setting from the average number of steps that is being executed?

You can gather statistics these and see what we get (http://llvm.org/docs/ProgrammersManual.html#the-statistic-class-stats-option):
STATISTIC(NumSteps,

  "The # of steps executed.");

STATISTIC(NumReachedMaxSteps,

  "The # of times we reached the max number of steps.");

STATISTIC(NumPathsExplored,

  "The # of paths explored by the analyzer.");

> reserve will preallocate 131072 bucket pointers 

>  (this gives a node capacity of double that). On a 64-bit system, that's a 1 MB allocation.

>  Note that the biggest savings are in avoiding the last rehashing. If we shrink the initial size, but still 

>  rehash frequently, we'll lose a lot of the benefits.


Please, update patches with full context: http://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface


http://reviews.llvm.org/D20933





More information about the cfe-commits mailing list