Those are probably all errortrace-based stacktraces. And the profiler uses the internal ones not the errortrace based ones. Figuring out how to get you internal stacktraces is probably a good idea. <div><br></div><div>But I think Vincent has adjusted the profiler to be able to use the errortrace stacks. I am not sure the state of that tho. </div>
<div><br></div><div>Robby<span></span><br><br>On Tuesday, April 22, 2014, Laurent <<a href="mailto:laurent.orseau@gmail.com">laurent.orseau@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div>Indeed, I have no stacktrace for the program `#lang racket (error "auie")` without `-l errortrace` (but I have one with it) on the command line.<br></div><div>(exceptions are printed, but line numbers are not)<br>
</div><div><br></div>When I run it inside DrRacket (where I do have traces) I still get an empty profile:<br>Profiling results<br>-----------------<br> Total cpu time observed: 710ms (out of 1232ms)<br> Number of samples taken: 337 (once every 2ms)<br>
Threads observed: 2<br><br>====================================<br> Caller<br>Idx Total Self Name+srcLocal%<br> ms(pct) ms(pct) Callee<br>====================================<br>
<br><br></div>Laurent<br></div><div><br><br><div>On Tue, Apr 22, 2014 at 3:57 PM, Robby Findler <span dir="ltr"><<a>robby@eecs.northwestern.edu</a>></span> wrote:<br>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">When I tried this on my machine I didn't get an empty profile so that is strange. <div><br></div><div>Do you get (non errortrace) stacktraces for errors in general?</div>
<span><font color="#888888"><div><br></div></font></span><div><span><font color="#888888">Robby</font></span><div><div><span></span><br><br>On Tuesday, April 22, 2014, Laurent <<a>laurent.orseau@gmail.com</a>> wrote:<br>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>No luck (empty profile). I also tried with errortrace and with providing/requiring main instead of dynamic-require and calling main in the profiling, but same effect.<br>
</div><div>
I had actually already tried also before posting, and this is why I used these explicit `time` and `current-milliseconds` calls.<br><br></div><div>I think the program itself is fast enough, but that it may make numerous X calls, that make Xorg use 100% cpu during those seconds.<br>
</div><div>No idea what these calls might be though.<br><br></div><div>I also tried on a different computer (older, but recent Mint), and it works fine. Looks very local to my computer then.<br>
</div><div><br></div><div>Laurent<br></div><div><br><div>On Tue, Apr 22, 2014 at 1:41 PM, Robby Findler <span dir="ltr"><<a>robby@eecs.northwestern.edu</a>></span> wrote:<br>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm not sure if this will work, but here's an attempt to profile a<br>
2htdp/universe program. If you put your program in one file called,<br>
say, tmp.rkt and then run the program below (closing the big-bang<br>
window after a while), you should get a profile of something. Maybe it<br>
will be useful.<br>
<br>
#lang racket<br>
<br>
(require profile)<br>
(profile<br>
(dynamic-require "tmp.rkt" #f)<br>
#:threads #t)<br>
<span><font color="#888888"><br>
Robby<br>
</font></span><div><div><br>
On Tue, Apr 22, 2014 at 6:30 AM, Laurent <<a>laurent.orseau@gmail.com</a>> wrote:<br>
> Thank you all for your answers. The problem seems to be on my end then.<br>
> However, some other graphic programs that draw in a canvas are not slow on<br>
> my computer.<br>
><br>
> Does `big-bang` do something in particular regarding graphics?<br>
><br>
> Laurent<br>
><br>
><br>
> On Mon, Apr 21, 2014 at 10:29 PM, David Vanderson<br>
> <<a>david.vanderson@gmail.com</a>> wrote:<br>
>><br>
>> It's fast for me - Linux Mint, both Racket 6.0 and 6.0.1.5 (from git just<br>
>> now) with cairo 2.11200.2.<br>
>><br>
>> Dave<br>
>><br>
>><br>
>> On 04/21/2014 11:10 AM, Laurent wrote:<br>
>><br>
>> My version of Cairo is 2.11000.2. What's yours, Sean?<br>
>> (probably: ls /usr/lib/i386-linux-gnu/libcairo.so*)<br>
>><br>
>><br>
>> On Mon, Apr 21, 2014 at 4:51 PM, Robby Findler<br>
>> <<a>robby@eecs.northwestern.edu</a>> wrote:<br>
>>><br>
>>> If the versions of Cairo are the same, then that eliminates one<br>
>>> possible route of inquiry.<br>
>>><br>
>>> Robby<br>
>>><br>
>>> On Mon, Apr 21, 2014 at 9:45 AM, Laurent <<a>laurent.orseau@gmail.com</a>><br>
>>> wrote:<br>
>>> > Thanks Sean.<br>
>>> > (I forgot to mention that I was testing on Racket 6.0.1.4).<br>
>>> > Apparently it does not lag on your machine, so it might be particular<br>
>>> > to my<br>
>>> > machine then? Strange.<br>
>>> ><br>
>>> ><br>
>>> > On Mon, Apr 21, 2014 at 4:32 PM, Sean Kanaley <<a>skanaley@gmail.com</a>><br>
>>> > wrote:<br>
>>> >><br>
>>> >> Here's my log after pasting the source into command-line racket 6.0,<br>
>>> >> Ubuntu 12.04 32-bit:<br>
>>> >><br>
>>> >> to-draw at 1649<br>
>>> >><br>
>>> >> to-draw: cpu time: 0 real time: 2 gc time: 0<br>
>>> >> on-key a at 2934<br>
>>> >> to-draw at 2934<br>
>>> >><br>
>>> >> to-draw: cpu time: 0 real time: 2 gc time: 0<br>
>>> >> on-key s at 2970<br>
>>> >> to-draw at 2970<br>
>>> >><br>
>>> >> to-draw: cpu </div></div></blockquote></div></div></div></blockquote></div></div></div></blockquote></div></div></blockquote></div>