profiling for gst

I am writing a byte code profiler for gst and had preliminary success. Right now it can record detail call graph and number of byte code executed in each method and export a report that is compatible with callgrind (valgrind) thus viewable with kcachegrind. The caveat is that the number of byte codes executed is not very representive of the actual time spent but this is as good as I can get without being too intrusive to the virtual machine.

It will be small (~100 lines of c code and ~200 lines of smalltalk) and intimate to the virtual machine so I think the best place for it to be is in the gst distribution itself. Is something like this desired? If so, I can polish it up, refresh it with the latest git head and post it as a couple of patches.

Derek    


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> I am writing a byte code profiler for gst and had preliminary success.
> Right now it can record detail call graph and number of byte code
> executed in each method and export a report that is compatible with
> callgrind (valgrind) thus viewable with kcachegrind.

Cool.  I had a minimal profiler based on Bags, but it didn't record
callgraphs.

> It will be small (~100 lines of c code and ~200 lines of smalltalk) and
> intimate to the virtual machine so I think the best place for it to be
> is in the gst distribution itself. Is something like this desired? If
> so, I can polish it up, refresh it with the latest git head and post it
> as a couple of patches.

Of course.  Anything contributed is acceptable.

However, you'll need to sign copyright papers.  I'll follow up privately.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> Is there a script to convert old syntax to new one? I write in old
> syntax but I think it need be consistant with the rest of the kernel
> files.

Yes, there is gst-convert (has --help option).  But you can start
posting the code in old syntax.

> 1, treat block calls the same as method calls.
> 2, pretend block calls do not exist and account the cost in blocks to
> their defining methods.
> Right now I am doing 2 because I think it is the lesser of 2 evils. Any thoughts?

It sounds like you have both implemented?  If so, adding an option
--separate-blocks would be the best.  Without seeing results, I cannot
make up my mind but I guess having only (2) at the beginning would be ok.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk