Ok So I did try to profile with the ProfileTools package.
Here is the code to generate a grind file:
Eval [
| file
result |
PackageLoader fileInPackage: 'ProfileTools'.
result := CallGraphProfiler profile: [PackageLoader fileInPackage:
'Seaside'].
file := FileStream open: 'grind.out' mode:
FileStream write.
file nextPutAll: result printString.
file close.
]
But I soon as I try to read it with KCachegrind
it fail to open the grind.out file.
Is there some missing header or
something else to append to the file?
Thanks
--Mathieu suen
----- Message d'origine ----
De : Paolo Bonzini <
[hidden email]>
À : Mathieu Suen <
[hidden email]>
Cc :
[hidden email]
Envoyé le : Jeu 27 mai 2010, 12h 22min 34s
Objet : Re: [Help-smalltalk] Having a bytcode loader
On 05/27/2010 11:52 AM, Mathieu Suen wrote:
> Hi,
>
> I have a little bit of free time so I decided to try implementing a
> bytecode loader and dumper. So I have a couple of question on what
> would be the right interface. And how people want this kind of
> feature.
>
> First do we wanted inside the *.st file or have it like in elisp a
> kind of *.stc file?
I think a *.stc file like Python and elisp would be better. The right interface IMO would be:
1) a gst-compile script to compile a .st file to .stc. This could reuse some of the infrastructure in gst-convert.
2) gst-package would check if a .stc file is present every time a .st file is put in an archive, and put the .stc file too.
3) Similarly, the PackageLoader would check if a .stc file is present and "file it in" too. I'm not sure whether the same file in primitive would be used for filein, or a different one.
> I part from that I have look at the ObjectDumper class. I wonder if
> that could help for building the bytcode dumper.
Maybe. However, first of all I'd start by profiling a large filein (Seaside) and see whether time is spent in Smalltalk or C code.
Paolo
_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk
Locked
