[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-devel
Subject:    Re: On Memory consumption of KDevelop-PG
From:       Milian Wolff <mail () milianw ! de>
Date:       2009-12-19 3:13:25
Message-ID: 200912190413.25514.mail () milianw ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday 19 December 2009 03:50:01 Milian Wolff wrote:
> Hey all!
> 
> I did a massif run with duchainify on Mediawiki, and well as far as I can
>  see there is no apparent memory leak.
> 
> http://mwolff.pastebin.com/f3581a8d6
> 
> What bugs me is the peak... See also:
> http://mwolff.pastebin.com/f4a66d631
> 
> I mean, it's pretty clear why we have a pretty high memory consumption:
> 
> - every visited node gets an Ast, even those that are just general helpers
> (AST == Tree.. duh)
> 
> - every Ast has two qint64 + a pointer _at least_, meaning: sizeof(AstNode)
>  == 32, most "specialized" nodes have at least one pointer to a child
>  element, so lets say sizeOf(node) = 36
> 
> - the phpfunctions file alone has 1.5 mio nodes (and this file is pretty
>  simple imo, no logical expressions or stuff like that which will likely
>  blow up the node number greatly, I mean the massif peak is somewhere
>  later, dunno how to find the exact file... but it's _not_ the internal
>  file)
> 
> so these nodes alone take up (36*1.5E6/(1024^2)) = 51.5 MB for the
> phpfunctions file...
> 
> Can't we reduce that somehow?
> 
> - is the ducontext pointer on _every_ node really neccessary? Imo it only
> makes sense for functions, classes and top-statements... At least the parts
>  in PHP where we use them can be changed to pass a currentContext(),
>  instead of using the ast-member.
> 
> But what about the context-builder etc. I mean esp. setContextOnNode and
> contextForNode... Afaik they are only relevant to nodes that actually
> correspond to contexts, right? I.e. to functions & classes.
> 
> Saving these 4 Bytes per node would decrease the size by 10%...
> 
> - do we really want to support gigantic source files, or why do we make
> startToken & endToken a qint64? Just making them int would save us 8 Bytes,
> i.e. 20%

just tried it out, only lowers the peak by <10MB (i.e. less than 10%) so maybe 
neglectable. But this shows something in my calculation is wrong...
-- 
Milian Wolff
mail@milianw.de
http://milianw.de

["signature.asc" (application/pgp-signature)]

-- 
KDevelop-devel mailing list
KDevelop-devel@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel


[prev in list] [next in list] [prev in thread] [next in thread]