faster copy-dereference to output

[stefanpenner]

@rwjblue r+

[jonnii]

@stefanpenner what does this mean for build times? (out of interest).

[stefanpenner]

@stefanpenner what does this mean for build times?

This is a nice improvement for users with a large number of files in dist, as it now only applies a "patch".
For normal apps, there appears to be no noticeable difference. for apps with many medium to large size files, more dramatic improvements exist. In my test, for 5000 photos, taking 3gb of disk the rebuild overhead went from 5s -> 23ms.

TL;DR it should be net positive, as it preforms a similar number of disk operations for testing what files are available, but typically skips nearly all file reading and writing (which turns out to be kinda slow).

[jonnii]

@stefanpenner interesting thanks!

[rwjblue]

The changes here look good, do you think we need any additional tests here (I'm not sure if we do)?

[stefanpenner]

do you think we need any additional tests here (I'm not sure if we do)?

I don't think so, the observable difference is performance. Which can be a-bit difficult to test, and the observed differences are thoroughly tested in the new module. So we should be covered.

If issues occur, it is most likely going to be in the foreign module, and further tests will then need to be added there, rather then here.

[stefanpenner]

this has some bugs, will investigate..

[stefanpenner]

Turns out, I was accidentally re-initializing the sync object each time... silly me.

[stefanpenner]

@homu r+

[homu]

📌 Commit e50b191 has been approved by stefanpenner

[homu]

⚡ Test exempted - status