00:41 geekosaur joined 01:49 ilbot3 joined 04:55 geekosaur joined 06:44 geekosaur joined
timotimo my poor system ... 08:24
08:36 domidumont joined
timotimo seems like dot -Tx11 somehow managed to put the x server in a state where it caused kwin and the plasma shell to continuously reboot its gpu-accelerated graphics subsystem 08:37
08:43 domidumont joined 09:48 domidumont joined 09:50 geekosaur joined
timotimo is the rec_depth field even correct? 09:58
like, when i limit to calls entries with a rec depth below 10, i still get a crazy amount of stuff 10:06
limited to 5, the amount is still 73k 10:09
huh, is thread_junction supposed to be recursive like that, i wonder 10:18
postcircumfix:<[ ]> and thread_junction both appear at a big amount of different depths in the call graph 10:21
11:00 geekosaur joined
MasterDuke_ timotimo: i think rec_depth is correct, but it may have been messed up with the recent changes (assuming you're talking about the sql output) 11:20
you could do a json profile and add a printf in the qt viewer to confirm they're the same 11:21
11:45 stmuk joined 11:49 stmuk_ joined 12:18 geekosaur joined
timotimo MasterDuke_: maybe i'm misunderstanding rec_depth 13:02
hack.p6c.org/~timo/rec_depth_errors.txt 13:05
if there was a consistent difference, that'd be fine 13:06
MasterDuke_ how are you calculating expected vs got? 13:07
timotimo gist.github.com/timo/c27778f00b62f...502ac0f0c2 13:08
it doesn't make sense to me that so many nodes would have rec_depth of 0
oh, rec_depth only counts how often the same routine has already been on the stack above the entry in question? 13:11
MasterDuke_ think so. it's needed to get inclusive time right 13:13
timotimo ah
yeah, that makes sense now 13:15
oh gott diese cops 13:29
auf der letzten seite
"letzte seite"
another mischan, hah 13:46
i now have little "progress bars" floating next to the edges
MasterDuke_ of your brownian thing? 13:51
timotimo nah, the brownian thing is impossible
MasterDuke_ impossible?
timotimo hack.p6c.org/~timo/forestfire_callgraph_2.svg 13:52
the svg file is 50 megabytes big
i can't view it with anything, i don't think
MasterDuke_ convert to png/jpg and crush it?
timotimo hm. 13:53
what program would do that? can convert do that?
ah convert uses inkscape to convert svg to png 13:54
MasterDuke_ ffmpeg might also
timotimo now how do i get the values for "out of the inclusive time of the parent of the routine i'm looking at right now, what percentage does this routine take in its inclusive time" 13:55
MasterDuke_ btw, all the progress bars look the same to me. or is that why you just asked that question? 13:56
timotimo yeah :)
convert: memory allocation failed `../dotrender.svg' @ error/svg.c/ReadSVGImage/2999. 13:57
MasterDuke_ i think you would need a subquery for that
timotimo fortunately, that's quite possible 14:00
MasterDuke_ we have the technology! 14:01
timotimo wait, why can't i just use the inclusive time column here?
14:09 geekosaur joined
timotimo nice, i've got a pretty for you 14:16
i uploaded it under the same filename 14:17
MasterDuke_ very cool 14:22
timotimo thx 14:44
MasterDuke_: can has sql help? 14:57
MasterDuke_ can offer one-handed help right now 14:58
timotimo oh, i think i got it
now i've gotta see why my values aren't right 15:06
MasterDuke_ two hands free for a bit, still working on it? 15:10
timotimo i'll paste you something
gist.github.com/timo/c27778f00b62f...502ac0f0c2 15:11
line 61 is where i'm trying to get a percentage for the time spent inside a routine itself, rather than spent in the child routines
oh 15:12
i think i should just have used the exclusive field and compared it against the inclusive field
m)
that at least gives me only values between 0 and 1 15:13
but sometimes nodes that have no children at all get 100% and sometimes 0%
MasterDuke_ hm, you're not adjusting inclusive time based on rec_depth?
timotimo aha got it
i am not 15:14
because now i am really interested in the inclusive time of every piece of the call graph
anyway, the subquery can just go away
MasterDuke_ ah, right 15:15
15:15 zakharyas joined
timotimo file:///home/timo/perl6/ecosystem/p6profiler-tui/forestfire_callgraph_3.svg 15:15
er 15:16
that's smart
hack.p6c.org/~timo/forestfire_callgraph_3.svg
MasterDuke_ what are some many of the bars in the boxes full? 15:18
*so many
oh, those are leaf nodes 15:19
timotimo yup, next step will be to throw the boxes out of those 15:20
oh, but how to do that 15:22
i might need a subquery for that, actually
refresh, it now has entry counts on the edges 15:25
f5 again and it'll have tooltips telling you what file a routine is from 15:27
F5 again for straight lines 15:34
15:41 mtj_ joined
MasterDuke_ nice 15:55
timotimo and with a _4, as said on #perl6, you get stuff sorted by inclusive time 16:29
this was a fun distraction
not even what i wanted to do :D
because for big callgraphs, dot will have some serious difficulty generating the target image 16:30
what i really wanted was a TUI with a tree that you could explore 16:40
it'd be a lot like the callgraph tab in the html profiler
17:37 domidumont joined 18:39 ZofBot joined 19:27 geekosaur joined 19:58 AlexDaniel joined 21:54 geekosaur joined
timotimo MasterDuke_: could it be i'm confusing caller_id and callee_id? 22:28
MasterDuke_: because i'm infinite looping while trying to get children because i get the same object over and over %)
or maybe sorting is bad 22:30
yeah, i think it was because i didn't sort right 22:32
22:51 ZofBot joined 22:57 AlexDani` joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!