Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/tools/cmd/godoc consumes unreasonable amounts of CPU power #7524

Closed
the42 opened this issue Mar 12, 2014 · 8 comments
Closed

x/tools/cmd/godoc consumes unreasonable amounts of CPU power #7524

the42 opened this issue Mar 12, 2014 · 8 comments

Comments

@the42
Copy link

the42 commented Mar 12, 2014

When godoc starts it re-indexes files every 5 minutes, even if there are no changes. A
better behaviour would be to re-index upon changes signaled by ionotify

What happened?
godoc consumes every 5 minutes unreasonable amounts of CPU power

What should have happened instead?
Only re-index files after a relevant file has changed
@gopherbot
Copy link

Comment 1 by bgarcia@golang.org:

Labels changed: added repo-tools.

Owner changed to bgarcia@golang.org.

@rsc
Copy link
Contributor

rsc commented May 21, 2014

Comment 2:

Labels changed: added release-none.

Status changed to Accepted.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@rsc rsc changed the title godoc consumes unreasonable amounts of CPU power x/tools/cmd/godoc consumes unreasonable amounts of CPU power Apr 14, 2015
@rsc rsc removed the repo-tools label Apr 14, 2015
@agnivade
Copy link
Contributor

It's not a simple slam dunk. There are couple of things to consider here -

  1. We are trading off CPU for memory here. It is a fair tradeoff but should be considered nevertheless. Each inotify watch takes the size of 1 inode, which is around 1kB (source). So, for around 1000 directories, we will consume 1MB of memory.

  2. There is an inherent limit specified by the OS to how many watches can be created. On linux, it is under /proc/sys/fs/inotify/max_user_watches. In my system, the value is 8192.
    Usually your $GOPATH would contain thousands of directories. In my machine, the no. of directories excluding .git under $GOPATH are 5473. An user can easily exceed this limit. In that case, the limit needs to be manually increased. Is that a good design ? Something to think upon.

But I agree that rebuilding the index unnecessarily even when nothing has changed, is worse off than this. I will prepare a CL.

/cc @andybons, @rsc - Thoughts ?

@andybons
Copy link
Member

Another alternative--though I'm not saying it's a good one--is to allow a flag to specify how often to index or to disable reindexing entirely. It's unclear what's better here. Whether to add yet another flag or increase the complexity of the code by adding inotify watches. The other issue with watches is that they're platform-dependent. On macOS you have to use the FSEvents API and I have no idea what you have to do on Windows.

@agnivade
Copy link
Contributor

agnivade commented Jan 24, 2018

It is already behind a flag called "index", which is false by default. And the index_interval is also behind a flag (default of 15 mins). So yes, you have to knowingly add a flag to enable indexing.

Secondly, I plan to use https://github.com/fsnotify/fsnotify which is fully cross-platform including Windows. Check out the repo.

But if you are satisfied with the flag solution, then I believe this issue can be closed.

@andybons
Copy link
Member

andybons commented Jan 24, 2018 via email

@agnivade
Copy link
Contributor

Great 👍

@agnivade
Copy link
Contributor

@andybons - I think you forgot to close this 😄

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants