[00:29] timotimo: hm, could we start profiling, enter/exit a frame a bunch, figure out how long that took, end profiling, discard what we've collected, and then start profiling again? [05:35] *** robertle left [05:37] *** Kaypie joined [05:37] *** Kaiepi left [06:03] *** sena_kun joined [07:00] *** reportable6 left [07:00] *** quotable6 left [07:00] *** greppable6 left [07:00] *** statisfiable6 left [07:02] *** brrt joined [07:02] \o [07:04] *** squashable6 left [07:04] *** releasable6 left [07:04] *** undersightable6 left [07:04] o/ [07:04] *** shareable6 left [07:04] *** evalable6 left [07:04] *** nativecallable6 left [07:04] MasterDuke: am working on a Perl 6 interface to the profiling info [07:05] see lib/MoarVM/Profiler.pm6 for WIP [07:07] *** coverable6 left [07:07] *** notable6 left [07:09] *** reportable6 joined [07:09] *** undersightable6 joined [07:09] *** releasable6 joined [07:09] *** squashable6 joined [07:10] *** quotable6 joined [07:11] *** statisfiable6 joined [07:11] *** evalable6 joined [07:11] *** greppable6 joined [07:11] *** nativecallable6 joined [07:11] *** shareable6 joined [07:28] the MoarVM::Profiler module could perhaps be something to get some unit tests that would at least find the worst breakages [08:08] *** notable6 joined [08:08] *** coverable6 joined [08:10] *** brrt left [08:14] *** Altai-man_ joined [08:16] *** sena_kun left [08:19] *** Altai-man_ left [08:20] *** sena_kun joined [08:37] ¦ MoarVM/configurable-subsystems: 6 commits pushed by (Timo Paulssen)++ [08:37] ¦ MoarVM/configurable-subsystems: a75bd02e8b | add more ops to confprog whitelist [08:37] ¦ MoarVM/configurable-subsystems: 3ec073f6b7 | add a #define to toggle debugspam from confprog [08:37] ¦ MoarVM/configurable-subsystems: a1154bcde2 | add heapsnapshot support to confprog [08:37] ¦ MoarVM/configurable-subsystems: 36b5339142 | draft support for multi-root call graph [08:37] ¦ MoarVM/configurable-subsystems: 700ac2e645 | fix 0 literal in confprog parser [08:37] ¦ MoarVM/configurable-subsystems: 70042d91ac | profiler_dynamic and profiler_static example [08:37] ¦ MoarVM/configurable-subsystems: review: https://github.com/MoarVM/MoarVM/compare/7cb64ae52dca...70042d91ac19 [08:37] oh [08:37] oh no [08:39] gitg's "discard selection" doesn't mean "unselect everything", it means "remove the selected changes from the files" [08:39] well, that's fun [08:43] that explains why it opens up a confirmation dialog [08:43] that i immediately clicked "ok whatever" on [08:43] ¦ MoarVM/configurable-subsystems: 7252cb0aa9 | (Timo Paulssen)++ | 3 files [08:43] ¦ MoarVM/configurable-subsystems: restore some changes that almost got nuked [08:43] ¦ MoarVM/configurable-subsystems: review: https://github.com/MoarVM/MoarVM/commit/7252cb0aa9 [08:45] fortunately "changes outside of vim detected, reload buffer from disk?" can be undone simply with the undo command [10:22] *** Voldenet left [10:39] *** brrt joined [10:47] *** krunen left [10:47] *** krunen joined [11:07] lizmat: i've seen the commits go by, glad to see all the enhancements to profiling. however, what i was asking about would have to take place in moarvm, an initial step to `profile` the cost of profiling a function so we can exclude that from the reported cost [11:07] MasterDuke: oki :-) [11:33] *** Voldenet joined [11:33] *** Voldenet left [11:33] *** Voldenet joined [12:08] lizmat: it's the sort of thing that might make sense to expose as an option to exclude or not via the api you have, since it won't be exact and someone might want the values included [12:13] afaik, the values returned by nqp::mvmendprofile are from code run since nqp::mvmstartprofile [12:13] and they're by thread [12:13] good * [12:13] so I don't think there's actually any additional hidden cost ? [12:16] lizmat: for the weekly, can you say that GSoC has started, that we have 2 new students working on MoarVM (and I think, one on perl6 documentation), and that (at least) one student already has a PR merged? :-) [12:16] do we have a link to the projects ? [12:19] *** Guest12727 joined [12:22] let me get it... [12:24] https://summerofcode.withgoogle.com/dashboard/project/4873743862595584/overview/ - dunno if this is a public link though [12:24] nope, needs a login :-( [12:24] https://summerofcode.withgoogle.com/organizations/4713351599357952/ this ought to be a public link though [12:29] yup, it is, thanks! [12:30] *** sena_kun left [12:36] lizmat: i think the cost of the profiling functionsMVM_profile_log_(enter|exit) are being included. iirc, that's why jnthn said `identity` has more that zero exclusive time in many of my profiles (it's essentially a no-op normally, but the added profiling functions means it can't be entirely removed) [12:36] ah, like that... hmmm [12:37] yeah, removing "indentity" from the profile usually makes sense :-) [12:39] so subtracting out the estimated cost of profiling should drop `identity` to near the bottom of profiles [12:46] *** sena_kun joined [13:35] *** sena_kun left [13:46] *** brrt left [13:51] *** zakharyas joined [13:58] *** patrickb joined [13:58] *** brrt joined [14:07] and another Perl 6 Weekly hits the Net: https://p6weekly.wordpress.com/2019/05/27/2019-21-thats-why/ [14:13] *** lizmat left [14:39] *** brrt left [14:40] *** zakharyas left [14:41] *** brrt joined [14:48] *** brrt left [15:38] *** patrickb left [15:55] *** zakharyas joined [16:25] *** robertle joined [16:55] *** patrickb joined [17:27] *** Elronnd left [18:05] *** MasterDuke left [19:20] *** SmokeMachine left [19:44] *** SmokeMachine joined [20:10] *** brrt joined [20:11] \o [20:29] *** zakharyas left [20:31] o/ [21:09] *** lizmat joined [21:37] \o [21:39] and just like that, it was too late already... [21:39] were you planning something? [21:46] fixing the world [21:47] oh, you know, being boiled to death isn't such a bad way to go [22:17] *** lizmat left [22:17] *** brrt left [22:24] *** patrickb left [22:29] *** lizmat joined [23:15] oh, the instrumented profiler leaks 100% of its collected data btw, haha [23:15] because so far the next thing after a profiler run has ended was that the program would output the data to a file and quit [23:17] but freeing all the data before returning the hash/list datastructures would be good for memory usage, too. as in, the dumping code could be run with much less memory pressure [23:55] *** MasterDuke joined [23:56] timotimo: that would be good, I’ve had profiles get killed by the oom killer when writing them out [23:57] *** MasterDuke left