Large size of live dumps in 2.6

[adrianbj]

Version: 2.6

Bug Description

Not sure if this is somehow specific to my implementation, but I've noticed that the size of a live dump in 2.6 is higher than 2.5. Here are some numbers to show what I mean. The tables below show the same dump once vs 100 times.

ONCE

	Live ON	Live OFF
2.5	3.8 K	204 K
2.6	44 K	204 K

100 TIMES

	Live ON	Live OFF
2.5	276 K	Out of memory
2.6	4.6 M	Out of memory

So as you can see, the size of the live dump in 2.6 is significantly greater than it is in 2.5.

Let me know if I can provide any additional info.

Thanks.

[dg]

I suppose you have a lot of dumps in Bar panels, right?

[adrianbj]

Well, the first example is 1 dump of a ProcessWire page object and the second example is 100 dumps of the same object.

The key thing is that in 2.6 the same dump is 12 to 16 times larger than it was in 2.5, so just wondering if you might know why and if it can possible be improved.

[dg]

I think I know why. I'll post here possible solution tomorrow, ok?

[adrianbj]

Tomorrow would awesome. It's late for you :)

[adrianbj]

Not really sure if it's related but I am noticing that the maxDepth limit mostly doesn't seem to apply to barDump() now that they are "live", so maybe that's why things are larger? But also, it seems like sometimes the limit is applied and I do get the [ ... ] indicator. Right now I am not really sure of the why/how this happens, but in complex/deep objects, it definitely seems to come into play. Let me know if you can't reproduce and I'll see what I can do about explaining / demonstrating it better.

BTW, is the plan that the maxDepth setting is actually no longer needed with barDumps?

And also, what is the plan for regular dumps? Do you plan on making these work with LIVE?

Thanks again for your efforts with this - it's really awesome!

[dg]

It actually changed a lot how live dump works in 2.6 a before 2.6. It has been unfinished for five years (#61, #62).

Now it works this way:

• every dump have encoded collapsed parts in JavaScipt (HTML representation is created when you click to open)
• dump with [Dumper::LIVE => true], is dump, that is completely encoded in JavaScript. It's good for places that are not visible after the page is loaded. So for places where you have to click to see them. (Bar panels, arguments in BlueScreen, etc)

Every dump generates two data, "dump data" (structure with pointers to snapshot) stored in HTML attribute data-tracy-dump, and "snapshot". Before 2.6 there was only one common snapshot stored in <script>Tracy.Debug.init(..., snapshot)</script>, since 2.6 there are a lot of snapshots stored in HTML attributes data-tracy-snapshot.

Everytime some object or array is changed, dump must create a new new snapshot.

Before 2.6 there was only one snapshot, so live-dumping (or JavaScript dumping) was not applicable to common dump(). Since 2.6 every dump() creates a new snapshot, so now it is possible that every collapsed data is in JavaScript.

On the other hand, when every dump() creates own snapshot, the size of page is bigger.

But there is way to tell to dump() „do not create new snapshot, because it is not needed, objects are still the same“. It is done using Dumper::SNAPSHOT option, see https://github.com/nette/tracy/blob/master/examples/dump-snapshot.php.

This is used for whole BlueScreen, not yet for Bar panels. Thats why now is output bigger.

[dg]

There are several ways to solve this problem. Thinking about how best way… Once I have it, I'll write you here.

[adrianbj]

@dg - thanks for the great explanation!

Regarding the maxDepth not being respected, I noticed that it is actually to do with live and the fact that it doesn't recognize recursion so the dump contain infinite levels if you expand an object that goes recursive.

Compare this:

to:

Note in the second screenshot, live is on and the page under filesManager is available to expand and here you can see that it just keeps going and going:

I expect this is not actually extra data being stored, but I still think it would be cleaner if these were marked as recursive.

Thanks.

[adrianbj]

@dg - just wanted to say thanks for the recursion fix - that's very helpful.

[dg]

This should be fixed.

[adrianbj]

@dg - just testing the new 2.6 version.

If I understand correctly, LIVE is no longer used, but LAZY is the default. Everything works for me with LAZY = true, but dumps are just as big as they were in the old version with LIVE = true, so I am not really seeing any effective change in size, but the time is much slower.

Let me know if I can provide more info to help.