Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 360229

Summary:

LocalFileNatives#nativeAttributes is very slow on Windows 7

Product:

[Eclipse Project] Platform

Reporter:

Heiko Böttger <heiko.boettger>

Component:

Resources

Assignee:

Szymon Ptaszkiewicz <sptaszkiewicz>

Status:

RESOLVED FIXED

QA Contact:

Severity:

major

Priority:

CC:

john.arthorne, remy.suen, sptaszkiewicz, Szymon.Brandys

Version:

3.6.2

Keywords:

performance

Target Milestone:

3.8 M3

Hardware:

OS:

Windows 7

Whiteboard:

Attachments:

Description	Flags
Patch v1	none
Patch v2	none

Description Heiko Böttger

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

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

2011-10-10 09:16:56 EDT

Created attachment 204879 [details]
Patch v1

Comment 3 Heiko Böttger

2011-10-11 08:05:49 EDT

Wow, that goes fast. Many thanks. 
Heiko

Comment 4 Szymon Ptaszkiewicz

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

2011-10-11 13:01:19 EDT

John, can you review this patch for me?

Comment 6 John Arthorne

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

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

2011-10-18 09:07:52 EDT

Looks good Szymon. Feel free to release this.

Comment 9 Szymon Ptaszkiewicz

2011-10-18 11:07:30 EDT

Thanks John! Fixed in master.