Hi there,
On Mon, 23 Jul 2012 17:09:19 +0200, Yury Semikhatsky <yu...@chromium.org>
wrote:
*Hi WebKit,
Almost all developers would like to know why the render process takes so
much memory. We are trying to address this problem by providing an
information on how much memory is consumed by some high-level WebKit
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:
To achieve that we instrumented several classes in
WebCore<http://code.google.com/searchframe#search/&q=reportMemoryUsage%20package:chromium&type=cs>to
report an estimation of their memory footprint. The main problem with
that approach is that it can be easily broken by changes to the
instrumented clasess. We need a way to guard from such changes that would
automatically validate the instrumentation and make sure it matches
current
class structure.
The goals are cool! Have you talked about how much code would be
introduced/changed by this approach?
We see several ways of doing that.
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.
I think we can't demand this from the committers. Although it seems a
trivial task to do the modification, it's too much effort to take care of
these individually. Can't we just automatize it somehow (or support the
modifications) with a clever script?
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.
This sounds a bit better for me, I think the effort that we put on tooling
will save time later. Since we can tell that when the change and its
instrumentation were introduced, the delay shouldn't be a big trouble.
We would like to know what you think about it and will greatly appreciate
any ideas and suggestions.
Done. :)
Regards,
Yury, Alexei, Ilya
*
Cheers,
<Zoltan>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
