Hi, > parts(DOM, CSS, JavaScript etc) . Currently there is a real-time chart in > Web Inspector that shows the render process memory broken down into > several > components:
Unfortunately this part is removed by the mail server, and from webkit-dev archives, but as far as I remember (we measured the memory consumption of webkit several times before), the main memory consumers were JavaScriptCore (to reduce GC calls) and Resource caches, not rendering. > First option we consider is to define a class with the same set of fields > as the instrumented one, then have a compile time assert that size of the > reference class equals to the size of the instrumented one. See > https://bugs.webkit.org/attachment.cgi?id=153479&action=review for more > details. > > Pros: compile time error whenever size of an instrumented class changes > with the appropriate modifications to the instrumentation function. > Cons: it will require each committer to adjust the reference class and the > instrumentation on any modification that affects size of the instrumented > class. Changes that don't affect size of the class will go unnoticed. This looks complicated and will likely break. > The second option is to write a tool/script/llvm-plugin and use it on a > build-bot to monitor the relevance of instrumentation and update it on > when > a new field is added to an already instrumented class. However, a question > remains who and how often would do this. > Pros: a committer may not need to update the instrumentation immediately. > Cons: the instrumentation may be behind the actual memory usage. An > addifitional effort required to create the tooling. Guys here have a lot of experience with static source code analysis, I can give their contacts if you interested. Regards, Zoltan _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
