git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC/PATCH] Documentation/technical/api-fswatch.txt: start with outline

From
Duy Nguyen <pclouds@gmail.com>
Date
Mar 13, 2013, 01:03 UTC
Message-ID
<CACsJy8CBru+Z0+oYVKGdwjiF4DDH3w4vCjunaoCnoDQ6AizwWg@mail.gmail.com>
In-Reply-To
<513FB85C.5010106@gmail.com>
On Wed, Mar 13, 2013 at 6:21 AM, Karsten Blees <karsten.blees@gmail.com> wrote:
> Hmmm...I don't see how filesystem changes since last invocation can solve the problem, or am I missing something? I think what you mean to say is that the daemon should keep track of the filesystem *state* of the working copy, or alternatively the deltas/changes to some known state (such as .git/index)?

I think git process can keep track of filesystem state (and save it down if necessary). But when git process is not running, system state changes and it cannot know about. The daemon helps filling this gap (and basically keeps git "running" (in a light form) throughout a development session). For example if we know only 5 files have changed since the last refresh, we only need to re-stat those 5. The same for untracked/ignored file checking,

> I'm also still skeptical whether a daemon will improve overall performance. In my understanding its essentially a filesystem cache in user-mode. The difference to using the OS filesystem cache directly (via lstat/readdir) is that we replace ~50k sys-calls with a single IPC call (i.e. the git <--> fswatch daemon communication is less 'chatty'). However, the 'chattyness' is still there between the fswatch daemon and the OS / inotify.

I think it attempts to reduce unnecessary system calls, not eliminate them all. In the "5 changed files" above, a few IPC calls are done to retrieve the file list, then 5 lstat will be issued (by git, not the daemon) instead of thousands of them.

>Consider 'git status; make; make clean; git status'...that's a *lot* of changes to process for nothing (potentially slowing down make).

Yeah. In my opinion, the daemon should realize that at some point accumulated changes are too much that it's not worth collecting anymore, and drop them all. Git will do it the normal/slow way. After that the daemon picks up again. We only optimize for the case when little changes are made in filesystem.

> Then there's the issue of stale data in the cache. Modifying porcelain commands that use 'git status --porcelain' to compile their changesets will want 100% exact data. I'm not saying its not doable, but adding another platform specific, caching daemon to the tool chain doesn't exactly simplify things...
>
> But perhaps I'm too pessimistic (or just stigmatized by inherently slow and out-of-date TGitCache/TSvnCache on Windows :-)

Thanks. I didn't know about TGitCache. Will dig it up. Maybe we can learn something from it (or realize the daemon approach is futile after all).

-- 
Duy
Previous: Karsten BleesNext: Karsten Blees
Message 7 of 17 in “Documentation/technical/api-fswatch.txt: start with outline”
  1. Documentation/technical/api-fswatch.txt: start with outlineRamkumar Ramachandra, Mar 10, 2013
  2. Heiko VoigtMar 11, 2013
  3. Ramkumar RamachandraMar 12, 2013
  4. Erik Faye-LundMar 12, 2013
  5. Jeff KingMar 12, 2013
  6. Karsten BleesMar 12, 2013
  7. Duy NguyenMar 13, 2013
  8. Karsten BleesMar 13, 2013
  9. Junio C HamanoMar 13, 2013
  10. Duy NguyenMar 14, 2013
  11. Pete WyckoffMar 15, 2013
  12. Thomas RastMar 16, 2013
  13. Ramkumar RamachandraMar 18, 2013
  14. Thomas RastMar 18, 2013
  15. Ramkumar RamachandraMar 25, 2013
  16. Duy NguyenMar 25, 2013
  17. Ramkumar RamachandraMar 25, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.