Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 360229 - LocalFileNatives#nativeAttributes is very slow on Windows 7
Summary: LocalFileNatives#nativeAttributes is very slow on Windows 7
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Resources (show other bugs)
Version: 3.6.2   Edit
Hardware: PC Windows 7
: P3 major (vote)
Target Milestone: 3.8 M3   Edit
Assignee: Szymon Ptaszkiewicz CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks:
 
Reported: 2011-10-07 09:21 EDT by Heiko Böttger CLA
Modified: 2011-10-18 11:07 EDT (History)
4 users (show)

See Also:

Attachments
Patch v1 (1.85 KB, patch)
2011-10-10 09:16 EDT, Szymon Ptaszkiewicz CLA 		no flags Details | Diff
Patch v2 (2.02 KB, patch)
2011-10-18 05:46 EDT, Szymon Ptaszkiewicz CLA 		no flags Details | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Heiko Böttger CLA 2011-10-07 09:21:17 EDT 
Build Identifier: 20110218-0911

I have a workspace with round about 100 java-projects some of them have contain over 5000 files. If I invoke the refresh-command on one of these projects it more than a minute to complete. I started to profile my eclipse and found that the org.eclipse.core.internal.filesystem.local.LocalFileNatives#nativeAttributes consumes a lot time. 

I don't know if this is only related to Windows 7 (32bit). When I replace the dll by an unloadable dummy to force eclipse to not use the native call everything is fine. Linux doesn't seem to have a problem.

Since the function is not invoked with any parameter would it be possible to cache the result?

For me this make eclipse nearly unusable since every time a builder/external tool needs to refresh a project i have to wait. Having 100 project it tooks up to an hour to refresh the whole workspace. 

Reproducible: Always

Steps to Reproduce:
1. Make sure the local_file_1_0_0.dll exists and your system is Windows 7
2. Create a project with over 5000 files (including svn-files)
3. Select the project and invoke refresh
---
4. replace the dll by a dummy implementation which returns false in dllmain or
 change LocalFileNatives#isUsingNatives to return "false"
5. refresh again and see that it is much faster
Comment 1 John Arthorne CLA 2011-10-07 09:52:04 EDT 
We should certainly be able to cache the result of calling nativeAttributes. I can't see any reason to call that more than once per Eclipse session.
Comment 2 Szymon Ptaszkiewicz CLA 2011-10-10 09:16:56 EDT 
Created attachment 204879 [details]
Patch v1
Comment 3 Heiko Böttger CLA 2011-10-11 08:05:49 EDT 
Wow, that goes fast. Many thanks. 
Heiko
Comment 4 Szymon Ptaszkiewicz CLA 2011-10-11 08:19:17 EDT 
(In reply to comment #3)
> Wow, that goes fast. Many thanks. 
> Heiko

Heiko, have you already tested the fix?
Comment 5 Szymon Ptaszkiewicz CLA 2011-10-11 13:01:19 EDT 
John, can you review this patch for me?
Comment 6 John Arthorne CLA 2011-10-12 16:24:23 EDT 
This is close, but note the nativeAttributes method doc:

	 * This is an optional method: if it has not been compiled
	 * into the native library, the client must catch the 
	 * resulting UnsatisfiedLinkError 

In your patch it will log an error message which will be confusing. This particular UnsatisfiedLinkError should be handled silently (the case where the library is present, but is missing this one function).
Comment 7 Szymon Ptaszkiewicz CLA 2011-10-18 05:46:57 EDT 
Created attachment 205401 [details]
Patch v2

Corrected patch to handle silently UnsatisfiedLinkError from #nativeAttributes().
Comment 8 John Arthorne CLA 2011-10-18 09:07:52 EDT 
Looks good Szymon. Feel free to release this.
Comment 9 Szymon Ptaszkiewicz CLA 2011-10-18 11:07:30 EDT 
Thanks John! Fixed in master.