This is an archive of the discontinued LLVM Phabricator instance.

[libc++] Add caching for feature-detection Lit tests
ClosedPublic

Authored by ldionne on Oct 7 2020, 1:55 PM.

Details

Reviewers
arichardson
Group Reviewers
Restricted Project
Commits
rG5390c5a96e97: [libc++] Add caching for feature-detection Lit tests
Summary

This significantly speeds up the configuration of libc++'s test suite
by making sure that we don't perform the same operations over and over
again.

Diff Detail

Event Timeline

ldionne created this revision.Oct 7 2020, 1:55 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 7 2020, 1:55 PM
Herald added a reviewer: Restricted Project. · View Herald Transcript
ldionne requested review of this revision.Oct 7 2020, 1:55 PM
ldionne accepted this revision as: Restricted Project.Oct 8 2020, 6:08 PM
This revision was not accepted when it landed; it landed in state Needs Review.Oct 8 2020, 6:09 PM
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.

Thanks, this is much better than my specialized version. However, I don't think it's correct since you are passing a reference to a mutable object to the cache so c.substitutions it will always be equal.
I just tested this and the cache will still hit if we append a value to config.substitutions between checks.

Thanks, this is much better than my specialized version. However, I don't think it's correct since you are passing a reference to a mutable object to the cache so c.substitutions it will always be equal.
I just tested this and the cache will still hit if we append a value to config.substitutions between checks.

Excellent catch! I fixed it in ddb2baf9fbff3d574c6c2bd69c2c9569100509a4.

I think copy.deepcopy() (as I used in D89109) should be a bit faster than pickle and also provide the same guarantee?

I think copy.deepcopy() (as I used in D89109) should be a bit faster than pickle and also provide the same guarantee?

Oops, I'm sloppy -- I had not seen your D89109 yet. Sorry about that. Does deepcopy allow us to use a dict? If not, I think I still prefer dumping to a string for simplicity. Speed isn't a huge concern here if we compare pickling to running the processes.

I think copy.deepcopy() (as I used in D89109) should be a bit faster than pickle and also provide the same guarantee?

However, pickle() allows storing it in a dict, so it might be better for lookups.

I think copy.deepcopy() (as I used in D89109) should be a bit faster than pickle and also provide the same guarantee?

Oops, I'm sloppy -- I had not seen your D89109 yet. Sorry about that. Does deepcopy allow us to use a dict? If not, I think I still prefer dumping to a string for simplicity. Speed isn't a huge concern here if we compare pickling to running the processes.

My bad, I should have linked the revision in this comment. I think doing the dict lookup is better since the cache ends up holding about 60 elements in some cases.