Skip to content

Commit

Permalink
Optimize symbol lookup at compunit creation time
Browse files Browse the repository at this point in the history
Do lexical lookup in setting whent already loaded. Reduces number of
calls to ModuleLoader by ~10 per each compunit creation.
  • Loading branch information
vrurg committed Mar 9, 2020
1 parent 40d41a3 commit 3583254
Showing 1 changed file with 5 additions and 1 deletion.
6 changes: 5 additions & 1 deletion src/Perl6/World.nqp
Expand Up @@ -518,6 +518,7 @@ class Perl6::World is HLL::World {
has int $!in_unit_parse;
has int $!unit_ready;
has int $!have_outer;
has int $!setting_loaded;
has $!setting_name;
has $!setting_revision;

Expand All @@ -526,6 +527,7 @@ class Perl6::World is HLL::World {
$!record_precompilation_dependencies := 1;
%!quote_lang_cache := {};
$!unit_ready := 0;
$!setting_loaded := 0;
$!in_unit_parse := 0;
}

Expand Down Expand Up @@ -714,6 +716,8 @@ class Perl6::World is HLL::World {
}
$/.unitstart();

$!setting_loaded := 1;

try {
my $EXPORTHOW := self.find_symbol(['EXPORTHOW']);
for self.stash_hash($EXPORTHOW) {
Expand Down Expand Up @@ -4938,7 +4942,7 @@ class Perl6::World is HLL::World {
# Make sure it's not an empty name.
unless +@name { nqp::die("Cannot look up empty name"); }

unless $!unit_ready {
unless $!setting_loaded {
return self.find_symbol_in_setting(@name);
}

Expand Down

2 comments on commit 3583254

@ugexe
Copy link
Member

@ugexe ugexe commented on 3583254 Mar 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is $!unit_ready even used anymore? Seems like you could just reuse that name and remove the existing $!unit_ready := lines even

@vrurg
Copy link
Member Author

@vrurg vrurg commented on 3583254 Mar 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The presense of setting doesn't mean that a unit is ready. Thus $!setting_loaded is more correct name here. Otherwise you're right and we can just get rid of $!unit_ready. My initial thought was that it might be useful for 3rd party code acting at compile time, but neither we expose the attribute to the public nor I can currently think of any code able to operate at such early stages of unit lifetime.

Please sign in to comment.