|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
| timotimo | > top objects by size | 01:39 | |
| [...] | |||
| Parameter 1,834,232 bytes | 01:40 | ||
| <anon MVMStaticFrameSpesh> 1,232,880 bytes | |||
| <anon MVMSpeshLog> 786,592 bytes | |||
| Method 753,920 bytes | |||
| by count: | |||
| <anon MVMStaticFrameSpesh> 4,242 | |||
| (there is only a single MVMSpeshLog it seems like) | 01:41 | ||
| it does have a whole crapton of references in it | 01:42 | ||
| MasterDuke | it would be nice if --full-cleanup didn't segv | 02:15 | |
| samcv | MasterDuke, yeah i used heaptrack to profile | 06:33 | |
| any tips are welcome | |||
| samcv puts on a cup of tea | 06:35 | ||
|
11:12
lizmat joined
11:49
MasterDuke left
|
|||
| nine | timotimo: are you still confused about the size/flags arg? The 2 lowest bits are about endianness. The next 2 bits are the log2 of the size in bytes, i.e. 0 -> 1 byte, 1 -> 2 bytes -> 2 -> 4 bytes, 3 -> 8 bytes | 11:55 | |
| timotimo | nine: ok, but why does it decide whether to shift by 1 or 2 to get the size? | 11:57 | |
|
12:04
lizmat left
|
|||
| nine | timotimo: just noticed that and testing the fix | 12:08 | |
| Geth | MoarVM: 81284a077a | (Stefan Seifert)++ | src/jit/graph.c Remove leftover bootstrap workaround - difference in readint's flags field When implementing endian switching for (read|write)u?int I discovered that I needed 2 bits for encoding endianness information. To get through NQP's bootstrap I temorarily took an unset endianness flat to signify the old 1 bit interpretation of the flags field. Apparently I forgot to remove the workaround in readuint's JIT implementation. Many thanks to timotimo++ for the discovery! |
12:14 | |
| nine | timotimo: there you go :) Sorry for the confusion | ||
| timotimo | \o/ | ||
| gzip allows storing an arbitrary null-terminated string in each block's header | 12:28 | ||
| and with FULL_FLUSH, a new block can be decompressed on its own without accessing earlier blocks | 12:29 | ||
| ebay engineers have figured out that the extra space needed for indices into the blocks in every block's comment isn't too big | |||
| and having these indices allows splitting gzipped files across multiple computation nodes | 12:30 | ||
| it'd be cool if the heap snapshot files wouldn't easily balloon up past gigabytes | |||
| gzip almost gets the file size down to 1/10 | 12:33 | ||
| even with -1 this one file goes from 115 megs to 23; whatever the default flag was got it down to 19 | 12:34 | ||
| i can't help but feel i can squeeze a bit more out of the format i already have | 12:43 | ||
| looking at it through xxd shows a whole lot of zeroes | |||
|
12:54
lucasb joined
|
|||
| timotimo | anyway, i investigated why sometimes there's objects without a name in the heap snapshot and it was a simple fix, yay | 13:12 | |
| oh, collectables aren't even variable-sized, only references are | 13:28 | ||
| though i think references tend to be a few times as big in total | |||
| cool. about 30% of all refs have only the cindex field set at all (with descr and kind both being 0) and out of those, 25% fit the cindex value into 16bit | 14:36 | ||
|
16:28
lizmat joined
|
|||
| timotimo | i'd really like for the heap snapshots to become about 50% smaller still ... but i don't think i can get that very easily | 18:09 | |
| so maybe using zlib would be smarter | 18:35 | ||
| only for writing out until the user wants to access it? | 18:38 | ||
|
18:48
MasterDuke joined,
MasterDuke left,
MasterDuke joined
|
|||
| MasterDuke | timotimo: or zstd perhaps? | 18:48 | |
| timotimo | MasterDuke: is zstd a cheap dependency? | 19:38 | |
| MasterDuke | timotimo: dunno | 19:45 | |
| timotimo | zlib is, like, everywhere | 20:02 | |
|
20:10
Util left
20:11
Util joined
21:14
Kaiepi left
21:15
Kaiepi joined
21:25
Kaiepi left
21:26
Kaiepi joined
|
|||