|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
| Geth | MoarVM/dump_all_heapsnapshot_data: 4570136a35 | (Timo Paulssen)++ | src/profiler/heapsnapshot.c Heapsnapshot: properly handle empty debug name the code was expecting empty debug names to be returned as null pointers, but the debug name API returns those as empty strings instead so that no null pointer checks are necessary. |
00:21 | |
| MoarVM/dump_all_heapsnapshot_data: 01464fbe06 | (Timo Paulssen)++ | src/6model/reprs/CStruct.c Heapsnapshot: Calculate CStruct unmanaged size |
|||
| MoarVM/dump_all_heapsnapshot_data: dfe3d8b415 | (Timo Paulssen)++ | src/profiler/heapsnapshot.c experiment to develop new heapsnapshot format don't forget to add -lz to the cflags and ldflags. this patch writes out all data in the heap snapshot collection as separate files (one per "field") into /tmp compressed through gzip. ... (5 more lines) |
|||
| timotimo | oh the first two commits can actually go on master, too | 00:22 | |
|
02:37
Kaiepi left,
Kaypie joined
05:04
Kaypie left
05:05
Kaiepi joined
05:47
robertle left
05:58
Kaiepi left
05:59
Kaiepi joined
|
|||
| nwc10 | good *, #moarvm | 07:12 | |
|
07:20
domidumont joined
|
|||
| timotimo | o/ | 09:03 | |
|
09:15
robertle joined
09:30
lizmat_ joined
|
|||
| nwc10 | \o | 09:31 | |
|
09:33
lizmat left
09:40
lizmat_ is now known as lizmat
|
|||
| jnthn | o/ | 10:15 | |
| timotimo | i'm wondering if maybe 32bit counters for the string heap, types, and static frames wouldn't be enough? | 10:17 | |
| jnthn | Those are within a single compilation unit. | 10:21 | |
| That'd mean you have a multi-gigabyte .moarvm file | |||
| What are you doing? :P | |||
| timotimo | i mean, they are currently 64bit big :) | 10:23 | |
| in the heap snapshot entries, i mean | |||
| line numbers are, too. they are 32bit in the MVMBytecodeAnnotation struct, though, so i'll shrink them as well | 10:24 | ||
| jnthn | Oh, I see :) | 10:43 | |
| timotimo | it doesn't make a noticeable file size difference. probably a combination of "there just aren't that many of them in the file" and "it goes through gzip, too" | 10:44 | |
| but writing the descrs as 8bit instead of 64bit made a big difference, even though gzip should kind of be able to figure that out? | 10:45 | ||
| of course it's good to have the post-gunzip data small as well, so i can read through it faster, so i'll not just turn everything into 64bit because "lol disk is cheap" | 10:46 | ||
| my original reason for wanting a smaller format is that something i wanted to analyze was quickly growing past 2 gigs and i had no clue if it even got past 1% done :D | 10:48 | ||
|
10:50
AlexDaniel joined
11:08
domidumont left
12:55
domidumont joined
|
|||
| timotimo | oh, i haven't even asked yet; is it fine to make zlib a dependency of moarvm? | 13:25 | |
| if need be, i'll make it a run-time dependency by using dlopen and falling back to a no-compression path | |||
| nwc10 | I might be biased (and not doing the work here) but if it's a runtime dependency with that sort of hoop-jumping, isn't doing the equivalent for zstd a better plan? | 13:28 | |
| it says "Zstandard is dual-licensed under BSD and GPLv2." but I've no idea how bad an idea it would be to bundle it instead. Sereal seems to inline 604K of source, instead of using a git submodule: github.com/Sereal/Sereal | 13:31 | ||
| er better URL, github.com/Sereal/Sereal/tree/mast...hared/zstd | |||
| (advantage over zlib is somewhat better compression, and faster. I believe that timotimo knows this, but not sure if the channel as a whole roughly knows this) | 13:32 | ||
| disadvantage is zlib has something like a 20 year headstart, so it's far more widely deployed already | 13:33 | ||
| timotimo | do we have Compress::ZStd? | 13:37 | |
| nwc10 | mmm, "not widely deployed" - I wasn't even sure that module existed. | ||
| It does. | |||
| but "no" will be the short answer, unless we bundle it or start having CPAN dependencies | 13:38 | ||
| timotimo | oh, that's for the heap analyzer tool, not moarvm itself | 13:39 | |
| for moarvm i'd use the original (?) C library | |||
| oh there's a zstandard wrapper library for zlib | 13:43 | ||
| so you could literally just replace the filename and be fine | |||
| nwc10: you think it'd be fine to not have dictionaries for the compression stuff? | 14:21 | ||
|
14:27
domidumont1 joined
14:30
domidumont left
|
|||
| nwc10 | errrr, I don't know for sure, but I'm going to say "guess so" | 15:10 | |
| timotimo | 'k | ||
|
15:19
Kaiepi left
15:24
Kaiepi joined
15:43
BeaconAlumna left
15:44
BeaconAlumna joined
16:27
robertle left
17:28
domidumont1 left
|
|||
| AlexDaniel loves zstd | 17:44 | ||
| high compression ratios with very fast decompression, now with long range mode and under a proper license without any tricks. Yaaay. | 17:45 | ||
|
17:55
robertle joined
|
|||
| lizmat | And another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2019/03/11/...sed-a-lot/ | 20:46 | |
|
21:09
robertle left
|
|||
| jnthn | lizmat++ # busy week! | 21:28 | |