Re: [CZT-Devel] Memory allocation with ArrayLists; arrays; etc.

[Tim M. <tm...@un...>]

Nice work!

When you say you added "parser = null", I assume you mean after you do 
the parsing? This would mean that, prior to your change, a reference to 
the parser is being kept even after the variable scope of the variable 
"parser" ends? That seems odd.

On 25/01/12 01:22, Leo Freitas wrote:
> Tim,
>
> I've forgot to mention below that I was talking about parsing and typechecking only.
>
> I've just run the same profiling setup on the VCG for these larger examples and yes, the worst ones were
> Object[] (24%), char[] (17.3%), ArrayList[] (9%) and BigInteger (2-3%).
>
> Surprising ones were int[] (6.5%) and short[] (6%) arrays, since they are not explicitly created anywhere in CZT.
> LocalAnn took 3%; Iterators were also a surprise: both iterator() and listIterator() cover about 10%, where more
> obvious ones like String (0.9%) and ZName (1.7%) were quite low.
>
> I've run the profiling sessions about 3-5 times on each example taking the average.
>
> ----
>
> Searching for potential sources of such unexpected types, I managed to find a few successful candidates:
>
> a) ParseUtils
>
> char[], short[], and int[] are mostly present in the Java CUP low-level classes to represent the internal parsing tables from the grammar.
> I simply added an explicit "parser = null" to the main ParseUtils.parse method. These arrays combined account for about 30% of memory.
>
> after the change, these arrays now account for 1.1% (!!!) that's quite an improvement.
>
> b) ListIterator and Iterator
>
> These appear in various places, but places that should influence all runs are only on SmartScanner (and possibly PrettyPrinter).
> After this change, they went from a combined (ListIterator + Iterator) 49% footprint to 17%; another good improvement.
>
> d) ArrayList and Object[]
>
> There are various places and identifying where are the ones of most significance is tedious/time-consuming.
> Instead, I've done a thorough search through various projects and changed default constructors to more sensible values, when possible,
> or to a parameterised default when not (e.g., PerformanceSettings interface in util project).
>
> This led to a decrease in the memory footprint of these objects of....
>
> e) BigInteger
>
> Why do we need big integers within LocAnn and other places? I guess because long would be potentially small?
> But would there really be something bigger than 2^32 or 2^64 in number of lines of source in a file say? Hum...
>
> In terms of memory footprint, it varied between 0.7% to 3%, depending on the example. I won't change this one for now.
>
> f) Garbage collection time
>
> Firstly it was about 16-20% now it was about 46.1% of time taken. Don't know if that's related to changes, but looks like it.
>
> ======
>
> Changes a) and b) led to a drastic memory footprint decrease from 8MB to 0.91MB;
> Other changes led to a minor improvement in comparison (i.e., 0.80MB).
>
> That's despite the fact that changes in d) were the most numerous - they didn't amount to much improvement, but some.
>
> Hopefully this will enable much better performance on larger specs. I am committing it now to see how it goes.
>
> Best,
> Leo
>
> On 23 Jan 2012, at 14:00, Leo Freitas wrote:
>
>> Hi Tim,
>>
>> That's interesting. I';ve been doing similar (profiling) tests over specs of some size (e.g., Mondex, Tokeneer, Xenon, IEEE float point unit);
>> although I guess they are smaller than iFACTS - apart from Xenon, which is quite large.
>>
>> On the profiling sessions, the worst culprit was "char[]" arrays, mostly from the java_cup lexer. The Object[] and ArrayList[] were about 2-3% each,
>> for what the char[] was 90% (!)... Similarly, on profiling CPU, it was the IO operations on zzRefill within the java_cup scanner that took the largest chunk
>> of the time (27%). Smart scanning (e.g., lookahead) has taken only about 2-3%.
>>
>> I wonder... what was the profilling setup that you used to get to the creation of Object[] ArrayList as the main problem?
>> Although the change you refer to below shouldn't be relatively simple to change, as Petra pointed out.
>>
>> I just want to get the right picture to tackle such performance problem for larger specs.
>>
>> Best,
>> Leo
>>
>> On 5 Jan 2012, at 23:51, Tim Miller wrote:
>>
>>> Hi everyone,
>>>
>>> Anthony Hall and I have been discussing some memory problems that CZT
>>> has when parsing large specifications. Anthony has been trying to
>>> typecheck the iFacts specification, but without much luck due to the
>>> large memory resources.
>>>
>>> We've each been playing around with VisualVM, and Anthony pointed out is
>>> that the two largest memory hogs are Object[] and ArrayList, taking up
>>> around 23% and 10% of the heap respectively.
>>> Most of the object arrays and ArrayLists contain exactly 10 items, and
>>> almost all items in these lists are null.
>>>
>>> After some poking around, I discovered that when ArrayList is created
>>> using the default constructor, it allocates 10 items initially. This
>>> appears to be where the 10 items come from in each case. I suspect this
>>> may also be contributing to some of the memory problems, considering
>>> that CZT has so many empty annotation lists, etc. Creating ArrayLists
>>> with an initial capacity of 0 or 1 (using the constructor ArrayList(int
>>> initialCapacity)) may give us some substantial space savings
>>>
>>> It appears that most ArrayLists are created in the gnast-generated code.
>>> Petra, how difficult would it be to create these lists using this other
>>> constructor?
>>>
>>> Regards,
>>> Tim
>>>
>>> ------------------------------------------------------------------------------
>>> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
>>> infrastructure or vast IT resources to deliver seamless, secure access to
>>> virtual desktops. With this all-in-one solution, easily deploy virtual
>>> desktops for less than the cost of PCs and save 60% on VDI infrastructure
>>> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
>>> _______________________________________________
>>> CZT-Devel mailing list
>>> CZT...@li...
>>> https://lists.sourceforge.net/lists/listinfo/czt-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Try before you buy = See our experts in action!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-dev2
>> _______________________________________________
>> CZT-Devel mailing list
>> CZT...@li...
>> https://lists.sourceforge.net/lists/listinfo/czt-devel
>
>