Skip to content

Potential performance regression from new LTO effort after export changes #71248

Closed

Description

@pnkfelix

Spawned off of #71131 (comment)

PR #71131 may have injected a performance regression into incremental compilation. It certainly seemed like it did on the two try runs we did on the PR itself:

So this issue is to track the investigation of that potential regression. (Namely, to evaluation whether a regression truly happened; assuming it did, then what its underlying causes were, and whether any of the significant sources of regression are avoidable.)

Activity

  1. self-assigned this
    on Apr 17, 2020
  2. added
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    I-slowIssue: Problems and improvements with respect to performance of generated code.
    I-compiletimeIssue: Problems and improvements with respect to compile times.
    A-incr-compArea: Incremental compilation
    and removed
    I-slowIssue: Problems and improvements with respect to performance of generated code.
    on Apr 17, 2020
  3. pnkfelix commented on Apr 17, 2020

    @pnkfelix
    ContributorAuthor

    Interesting: I instrumented the first case I was interested in ("is valid cap letter" on regex, as noted here), and it reports that in all five of the cases where we are now not reusing the Post-LTO build product, it is because the exports_all_green boolean is false; the set comparison test that I was worried about isn't even being run!

    I'll have to go back and review the original logic about the all-green flags; I will admit that when I transcribed that part of the code, it was more a blind "well surely this matters" kind of reasoning.

  4. pnkfelix commented on Apr 17, 2020

    @pnkfelix
    ContributorAuthor

    (My intuition is that we do need the exports_all_green computation, and when it is non-green we do need to re-do LTO. After all, the basis of #69798 (comment) was that a global symbol in module A was determined to be unused in module B, and thus the global symbol was demoted to a local to A; then a later change to B injected a use of that global symbol, and so the change to the importing module (B) is significant to the compilation of A.

    Another, separate question is whether injecting { } (as the "is valid cap letter" patch does) can be made something that doesn't trigger this code to treat changed module as non-green here...)

  5. pnkfelix commented on Apr 17, 2020

    @pnkfelix
    ContributorAuthor

    (My intuition is that we do need the exports_all_green computation, and when it is non-green we do need to re-do LTO. After all, the basis of #69798 (comment) was that a global symbol in module A was determined to be unused in module B, and thus the global symbol was demoted to a local to A; then a later change to B injected a use of that global symbol, and so the change to the importing module (B) is significant to the compilation of A.

    Having said that, I did prototype taking out exports_all_green, and with it gone, the regression test for #69798 still passes...

  6. pnkfelix commented on Apr 17, 2020

    @pnkfelix
    ContributorAuthor

    I suppose if the import map actually reflects the true usage of the symbols in the importing module, then in fact it should not be necessary for us to look at exports_all_green.

    I'm willing to have a go with a PR that removes it and see how things go.

  7. added a commit that references this issue on Apr 18, 2020
  8. added a commit that references this issue on Apr 20, 2020
  9. added a commit that references this issue on Apr 21, 2020
  10. Mark-Simulacrum commented on Apr 29, 2020

    @Mark-Simulacrum
    Member

    @pnkfelix Now that #71267 has landed, I'm going to go ahead and close this but feel free to reopen if you think there's more to track here.

  11. fenollp commented on May 3, 2020

    @fenollp

    I've opened #71850 which seems related.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

A-incr-compArea: Incremental compilationI-compiletimeIssue: Problems and improvements with respect to compile times.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions