[PATCH] D20933: Preallocate ExplodedNode hash table

[Ben Craig via cfe-commits]

bcraig added a comment.

In http://reviews.llvm.org/D20933#452352, @zaks.anna wrote:

> > For the pile of LLVM projects that I am currently building (llvm, clang, libcxx, libcxxabi), 18.9% of all analyzed
>
> >  functions hit the maximum step count. For the previously discussed large .C file, 37% of the analyzed functions hit the maximum step count.
>
>
> These look high to me. I've looked up some statistics that I've collected years ago and I see a similar number for sqlite, but much lower numbers for other test cases. I tested with the Preview app (~150 files) and a bunch of preprocessed files we had on hand at that moment in both cases the number of reaching timeout was about 1%. sqlite is special because all source code is in that one file, so we can do much more inlining. Which C test case have you used?
>
> (I do not have any numbers for C++.)
>
> Another wrinkle here is that we support "Analyzer shallow mode" (-analyzer-config mode=shallow) , which dials down inlining quite a bit. We have users who analyze during build (believe it or not) and they use the shallow mode by default.


I've run another analysis, this time on a code base that is mostly C (maybe 5% C++).  6% of the functions there hit the max.  The average number of steps was 13439, and the median is 2867.

Analyzer shallow mode does adjust inlining.  It also lowers the maximum number of steps from 150000 to 75000.  That reduction in number of steps drops the exploded graph reservation down to half a meg instead of the full megabyte.


http://reviews.llvm.org/D20933