--profile produces too large files and numbers

[greenfork]

The Problem

When I try to profile MUGS, it produces nonsensical to me data.

Expected Behavior

Produces good profile data.

Actual Behavior

It produces large files 50-80 MiB in size, they are too slow to load and have too large numbers in them.

Steps to Reproduce

zef install MUGS
raku --profile $(which mugs-cli) adventure
^D

Environment

• Operating system: Arch Linux
• Compiler version (rakudo -v or raku -v):

Welcome to Rakudo™ v2024.02.
Implementing the Raku® Programming Language v6.d.
Built on MoarVM version 2024.02.

[demanuel]

I can reproduce this with the latest rakudo version. My firefox takes ages to load the report, and the report is mostly unusable.

[niner]

The HTML profiler output is really only suitable for quite small programs as the profile data necessarily gets quite large. For a much better performing profiler look at https://github.com/timo/moarperf

[MasterDuke17]

Comma also has a built-in profile viewer that uses (or maybe only can use, I don't remember exactly) the sql output, so it can handle much larger profiles. There are some known problems with the profiler creating actually bad output, those two tools don't help with that, but do at least let you look at very large profiles.

…

On Mon, Apr 15, 2024 at 7:30 AM niner ***@***.***> wrote: The HTML profiler output is really only suitable for quite small programs as the profile data necessarily gets quite large. For a much better performing profiler look at https://github.com/timo/moarperf — Reply to this email directly, view it on GitHub <#5552 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACOHYUOQ6OYUZVGZ6OKEWITY5O235AVCNFSM6AAAAABGFMUAWOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANJWGYYDGNBRG4> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[timo]

There's also a known issue with the profiler that using "exit()" inside your code can cause the profile output to be pretty messed up. I haven't looked at MUGS, but it's possible that has something to do with it. I'm not sure how we can even get these really long numbers you're seeing in the screenshot, though

[MasterDuke17]

There's also a known issue with the profiler that using "exit()" inside your code can cause the profile output to be pretty messed up.

This patch from @niner might be able to help with a workaround in this case:

diff --git a/src/vm/moar/HLL/Backend.nqp b/src/vm/moar/HLL/Backend.nqp
index 098e8a30c..479297251 100644
--- a/src/vm/moar/HLL/Backend.nqp
+++ b/src/vm/moar/HLL/Backend.nqp
@@ -51,9 +51,9 @@ class HLL::Backend::MoarVM {
     method run_profiled($what, $kind, $filename?) {
         $kind := 'instrumented' unless $kind;
 
-        my @END := nqp::gethllsym('perl6', '@END_PHASERS');
-        @END.push(-> { self.dump_profile_data($prof_end_sub(), $kind, $filename) })
-            if nqp::defined(@END);
+        #my @END := nqp::gethllsym('perl6', '@END_PHASERS');
+        #@END.push(-> { note("dumping in END"); self.dump_profile_data($prof_end_sub(), $kind, $filename) })
+        #    if nqp::defined(@END);
 
         self.ensure_prof_routines();
 
@@ -67,10 +67,10 @@ class HLL::Backend::MoarVM {
         }
 
         my $res  := $what();
-        unless nqp::defined(@END) {
+        #unless nqp::defined(@END) {
             my $data := $prof_end_sub();
             self.dump_profile_data($data, $kind, $filename);
-        }
+        #}
         $res;
     }