Fotios Valasiadis

Well short syncs also give me crazy speed sometimes, just got `12GB/s` after syncing. Didn't manage a negative value though. I imagine though that having lengthier interactions will actually give...

The day has come people, remember to close the issue as completed when you update to electron 30!

> Looking at [electron/electron#10515](https://github.com/electron/electron/issues/10515) it seems that some electron bits might also be required to get this to work. > > And then its gated to windows on the frontend...

Oh we actually have to wait for electron to support it separately, I see. Well no big deal, will manage with vanilla chromium till then!

This PR #132 , makes the changes described above. As a result the new measurement for the build while `build_recorder` wraps it is **7.882s**, which means an overhead of **0.948s**...

Given the problems we encountered at #136, we can now confirm that the hash check isn't in vain. The performance overhead isn't to be ignored though so I think the...

So after properly profiling the code using valgrind. Even after the "optimization" mentioned above the three critical points in term of performance are: 1. Computing the hash of each file,...

@zvr Well an update, after some extra tests. It's the file reading that cripples performance, not the hash itself. So that's the best we can get! Unless we can improve...

@zvr What about two options? 1. One that assumes an immutable OS. 2. One that assumes the build files are not to be modified by **ANY** external source These give...

Well after thinking about it the solution was rather simple: The only thing that `rename_exit` cannot access when compared with its `rename_entry` counterpart is the absolute path of the `oldpath`....