RE: [PATCH v5 7/7] fsmonitor: add a performance test

-----Original Message-----
From: Junio C Hamano [mailto:jch2355@gmail.com] On Behalf Of Junio C
Hamano
Sent: Friday, July 7, 2017 2:35 PM
To: Ben Peart <redacted>
Cc: git@vger.kernel.org; benpeart@microsoft.com; pclouds@gmail.com;
johannes.schindelin@gmx.de; David Turner [off-list ref];
peff@peff.net; christian.couder@gmail.com; avarab@gmail.com
Subject: Re: [PATCH v5 7/7] fsmonitor: add a performance test

Ben Peart [off-list ref] writes:

quoted

On 6/14/2017 2:36 PM, Junio C Hamano wrote:

quoted

Ben Peart [off-list ref] writes:

quoted

quoted

Having said all that, I think you are using this ONLY on windows;
perhaps it is better to drop #ifdef GIT_WINDOWS_NATIVE from all of
the above and arrange Makefile to build test-drop-cache only on
that platform, or something?

I didn't find any other examples of Windows only tools.  I'll update
the #ifdef to properly dump the file system cache on Linux as well
and only error out on other platforms.

If this will become Windows-only, then I have no problem with
platform specfic typedef ;-) I have no problem with CamelCase,
either, as that follows the local convention on the platform (similar
to those in compat/* that are only for Windows).

Having said all that.

Another approach is to build this helper on all platforms, ...

... and having said all that, I think it is perfectly fine to do such a clean-up long
after the series gets more exposure to wider audiences as a follow-up patch.
Let's get the primary part that affects people's everyday use of Git right and then
worry about the test details later.

A quick show of hands to the list audiences.  How many of you guys actually
tried this series on 'pu' and checked to see its performance (and correctness ;-)
characteristics?

Do you folks like it?  Rather not have such complexity in the core part of the
system?  A good first step to start adding more performance improvements?  No
opinion?

I have not had the chance to test the latest version out yet.  The idea, broadly, seems sound, but as Ben notes in a later mail, the details are important.  Since he's going to re-roll with more interesting invalidation logic, I'll wait to try it again until a new version is available.