Unnecessary Junk in config_lib.pasm Slows Startup

[chromatic]

In a freshly-configured Parrot, config_lib.pasm is 18k. Part of the build
process turns this file into a frozen PMC. During global initialization,
Parrot thaws this into a Hash PMC used in the root set -- the Parrot
configuration Hash.

This Hash contains such useless information as which warning flags the compiler
used to build Parrot supports (61 per my count), ExtUtils::MakeMaker commands
used in Makefiles on platforms which do not have native commands for touch or
chmod (for example), and system library symbols (86 per my count).

It does contain some useful configuration information, such as expected library
path prefixes.

Disabling the configuration hash altogether speeds up Parrot startup by 13.23%,
but tends to break libraries such as PGE which rely on library path prefixes.

Note that all of this information is also available from config.pir.

We should review the information passed through to src/parrot_config.c and
remove entries which are unnecessary. We can expose more of this information
through config.pir, where programs that rely on it can use it directly.

-- c
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

[Nick Glencross]

Hi all,

On Fri, May 15, 2009 at 11:37 PM, chromatic <chro...@wgz.org> wrote:
> In a freshly-configured Parrot, config_lib.pasm is 18k.  Part of the build
> process turns this file into a frozen PMC.  During global initialization,
> Parrot thaws this into a Hash PMC used in the root set -- the Parrot
> configuration Hash.

One potential factor in the significant time to unfreeze the PMC is
that a significant number of GCs are performed to work around the bug
described around line 1764 of pmc_freeze.c. I recently removed the '1
||' to see if it had been fixed, but it still asserts in hash.c:515.

It might be worth seeing if the hash unfreezing can be fixed easily as
it potentially impacts the performance of unfreezing PMCs elsewhere.

Nick
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

[Mark Glines]

chromatic wrote:
> In a freshly-configured Parrot, config_lib.pasm is 18k. Part of the build
> process turns this file into a frozen PMC. During global initialization,
> Parrot thaws this into a Hash PMC used in the root set -- the Parrot
> configuration Hash.
>
> This Hash contains such useless information as which warning flags the compiler
> used to build Parrot supports (61 per my count), ExtUtils::MakeMaker commands
> used in Makefiles on platforms which do not have native commands for touch or
> chmod (for example), and system library symbols (86 per my count).

Okay. The information might be redundant, but it was still being used.
In r38830, I reverted your r38804 patch because it caused build
failures on darwin/OSX; apparently pbc_to_exe is compiled by a tool
written in PIR which was relying on the "ccflags" variable from
config_lib.pasm. When your patch made that variable go poof, it tried
to run gcc with very mimimal arguments, and we were relying on an -I
option to find system headers, so the build broke. See TT #675.

I've since made a patch that reapplies r38804 with a whitelist for a
small group of useful-looking items, but...

> Note that all of this information is also available from config.pir.

So instead of the patch I mentioned above, I guess we should convert
tools/dev/pbc_to_exe.pir to use config.pir instead of config_lib.pasm.
That seems reasonable to me, I'll see what I can do.

Mark
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

[Mark Glines]

Mark Glines wrote:
>> Note that all of this information is also available from config.pir.
>
> So instead of the patch I mentioned above, I guess we should convert
> tools/dev/pbc_to_exe.pir to use config.pir instead of config_lib.pasm.
> That seems reasonable to me, I'll see what I can do.

Fail. The above tool *does* use config.pir; removing the items from
config_lib.pasm also made them unavailable via config.pir. I'll leave
r38804 reverted for now.

Mark
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

[Mark Glines]

Mark Glines wrote:
> I've since made a patch that reapplies r38804 with a whitelist for a
> small group of useful-looking items,

For the curious, that patch is attached. It's probably safe to apply
right now, or we can wait until after the release, or we can handle the
requirements of pir builds through some other means. I don't feel too
strongly either way; I just don't want to see chromatic's optimization
work get dropped on the floor.

Mark