On Wed, Jul 13, 2005 at 12:29:29AM -0400, Will Coleda wrote:
> Ah, there we go. partcl is back down to about 4.5 times slower.
> Running a trace, I see the top two opcodes are:
>
> Code J Name Calls Total/s Avg/ms
> 177 - compile_p_p_s 2 0.088355 44.177380
> 537 - load_bytecode_sc 6 0.034809 5.801486
>
> Which combined only make up .122s - not enough to get us back down to
> even, but it's a start. There are no compile opcodes in the path for
> "hello.tcl", so this has to be coming in through something we're
> loading:
>
> load_bytecode "library/Data/Escape.pbc"
> load_bytecode "library/PGE.pbc"
> load_bytecode "library/PGE/Glob.pbc"
The only compile opcodes that are executed by PGE are when a rule
is compiled (to convert from PIR source to a subroutine PMC).
If partcl or hello.tcl is using PGE at all, then there will be at
least one compile for each rule it uses. (Perhaps there aren't
any.)
> Can any of these stdlib items be optimized so they load faster?
> Anything they're doing at load time that could have been done at
> compile time instead - like the hash init in PGE::EXP && P6Rule, or
> the rule compilation in PGE::Rule.
Well, for this I need more details about the load/compile process
that Parrot uses when creating a .pbc file. In particular, given
that the PGE.pbc file is created by doing
parrot -o PGE.pbc --output-pbc PGE.pir
is the @LOAD subroutine in PGE.pir executed when parrot compiles it
or when PGE.pbc is loaded? (I suspect the latter.)
More generally, how does one save precompiled tables into a .pbc
file...? I haven't seen quite how to do this yet...
Pm
