Stream: t-compiler/wg-incr-comp

Topic: #77070


view this post on Zulip Aman Arora (Nov 07 2020 at 07:31):

I ran a test for this again locally by building regex using rustc 1.49.0-nightly (a601302ff 2020-11-06) and using my local build

I'm not sure if the implementation is correct (essentially if I should be using virtual_depnode_index), but the results didn't seem to improve incremental cache size or compile times.

Compilation times:

build description cpu time (s)
nightly cargo clean debug 27.891
nightly touch src/libr.rs 7.343
self cargo clean debug 36.157
self touch src/libr.rs 9.069

I got the times using measureme summarize

build description size in bytes
nightly cargo clean debug 25216
nightly touch src/libr.rs 25176
self cargo clean debug 25796
self touch src/libr.rs 25744

I got size by running du -s target/debug/incremantal/regex-<>

view this post on Zulip Aman Arora (Nov 07 2020 at 07:41):

I'm curious if the nightly is a debug build? If not then that might have had some reason for the difference in times, since my local build is built with debug_assertions on.

view this post on Zulip Aman Arora (Nov 07 2020 at 07:42):

regex-stage1-touch-librs.mm_profdata regex-stage1-clean.mm_profdata regex-nightly-touch-librs.mm_profdata regex-night-clean.mm_profdata

If anyone wants to look at the self profile data, files marked with stage1 is my local build

view this post on Zulip lqd (Nov 07 2020 at 10:49):

(IIRC nightlies don't have debug_assertions nor llvm assertions, you may have to compare two local builds, one on master and one with your PR applied)

view this post on Zulip Tyson Nottingham (Nov 07 2020 at 20:23):

It shouldn't be using virtual_depnode_index (though it might not matter because I don't think that code ever executes), but I think there are other issues. I'll comment on the PR when I get a chance.

view this post on Zulip Aman Arora (Nov 07 2020 at 20:57):

Tyson Nottingham said:

It shouldn't be using virtual_depnode_index (though it might not matter because I don't think that code ever executes), but I think there are other issues. I'll comment on the PR when I get a chance.

thanks :smile:

view this post on Zulip Aman Arora (Nov 11 2020 at 21:23):

Thanks for the thorough details @Tyson Nottingham. Looks like this going to be a lot more work than I had anticipated, especially since I'm missing quite a bit of background. My current focus is landing RFC-2229, but I can probably pick it up sometime after mid-December.

Also if I recall correctly @Wesley Wiser mentioned we only have one query marked anonymous, so not sure how much time/memory savings we will be able to achieve.

I suggest we close this PR since it's way off from the implementation it's supposed to be.


Last updated: Oct 21 2021 at 20:03 UTC