-
Notifications
You must be signed in to change notification settings - Fork 47
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
The JNA implementation seems unbarably slow on Windows (7) #143
Labels
Comments
Thanks for the report @spangaer |
Confirming improvement by system property flag.
All have consistent improvement. It's not blazingly fast, because it generates 300k file related procmon entries for a single run. But only between 0 and 5 (across runs) are over 1 second instead of hundreds, the remainder is in the millisecond or sub-millisecond range and at least the CPU is doing something else then waiting for timestamp info. |
Open
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When running things like
sbt eclipse
SBT munches through the local Ivy repository very aggressively. On Windows it used the JNA code for thisand it seems to be unbearably slow. Many of the file accesses take multiple seconds twice, once to figure out a symlink that needs to be resolved (repo is relocated via symlink) and once to access the actual file. (observed via procmon)
Because these slow cases run in the hundreds (for certain projects; iterates multiple times too), it can take up to 15 minutes to munch through.
When enabling
-Dsbt.io.jdktimestamps=true
the same file access becomes sub millisecond. (I will re-iterate on Monday with a cold(er) system to verify).This is a:
The text was updated successfully, but these errors were encountered: