HeapProfiler: very slow ~4min "take snapshot time" for 80MB gmail heap.

HeapProfiler: very slow ~4min "take snapshot time" for 80MB gmail heap.

The reason of that is a number of cons strings in the app.
The app constructs a json string and as a result v8 heap has
a very long chain of cons strings.

Profiler counts all these strings as plain String objects and
assign the content of the strings as node names.

It required O(n^2) time and O(n^2) memory.

Solution: I introduced two new types, kConsString and kSliced string.
They do not use the content of the string for names. So the problem disappeared.

The heap profiler usability problem will be solved on Blink side.

BUG=285770
R=yangguo@chromium.org

Committed: https://code.google.com/p/v8/source/detail?r=16611

[Yang, 2013-09-10 08:47:56]

Having the string content appear as name seems valuable. How about setting a
certain limit so that we stringify only strings with lengths below that limit?
That way, whether to show string content would not depend on the string type.

[loislo, 2013-09-10 08:56:29]

On 2013/09/10 08:47:56, Yang wrote:
> Having the string content appear as name seems valuable. How about setting a
> certain limit so that we stringify only strings with lengths below that limit?
> That way, whether to show string content would not depend on the string type.

we have had 1k limit for the strings but
it doesn't solve the problem because the cons string uses only 40 bytes.
So in our case we use 25 times more memory.

I will reconstruct and show the content of the cons and sliced strings on
DevTools front-end side.
Usually we show only 100 strings at a time. So it wouldn't be a performance
issue.

[Yang, 2013-09-10 09:16:44]

On 2013/09/10 08:56:29, loislo wrote:
> On 2013/09/10 08:47:56, Yang wrote:
> > Having the string content appear as name seems valuable. How about setting a
> > certain limit so that we stringify only strings with lengths below that
limit?
> > That way, whether to show string content would not depend on the string
type.
> 
> we have had 1k limit for the strings but
> it doesn't solve the problem because the cons string uses only 40 bytes.
> So in our case we use 25 times more memory.
> 
> I will reconstruct and show the content of the cons and sliced strings on
> DevTools front-end side.
> Usually we show only 100 strings at a time. So it wouldn't be a performance
> issue.

I was rather thinking about the string length than the object length on the
heap. If we so far read the entire content of the string, it should be easy to
read the string length first, right?

[Yang, 2013-09-10 09:32:47]

On 2013/09/10 09:16:44, Yang wrote:
> On 2013/09/10 08:56:29, loislo wrote:
> > On 2013/09/10 08:47:56, Yang wrote:
> > > Having the string content appear as name seems valuable. How about setting
a
> > > certain limit so that we stringify only strings with lengths below that
> limit?
> > > That way, whether to show string content would not depend on the string
> type.
> > 
> > we have had 1k limit for the strings but
> > it doesn't solve the problem because the cons string uses only 40 bytes.
> > So in our case we use 25 times more memory.
> > 
> > I will reconstruct and show the content of the cons and sliced strings on
> > DevTools front-end side.
> > Usually we show only 100 strings at a time. So it wouldn't be a performance
> > issue.
> 
> I was rather thinking about the string length than the object length on the
> heap. If we so far read the entire content of the string, it should be easy to
> read the string length first, right?

Then again, if it makes no difference on the front end, and you lazily
reconstruct the string content, it seems fine. LGTM.

[loislo, 2013-09-10 11:12:47]

Committed patchset #1 manually as r16611 (presubmit successful).