| Pathological Performance Problem with MarkerUtilities [message #287196] |
Mon, 27 June 2005 09:10  |
Eclipse User |
|
|
|
I've apparently done something seriously wrong here ...
Using Eclipse 3.1RC2 on WindowsXP Pro SP2
We're building a feature from a number of plugins which manipulates
files on a remote system which exposes its file system by something
very much like SAMBA.
We have our own project wizard which adds files to our projects by
creating links to the remote files in order to cope with odd
permission and file-naming practices on the remote system.
Up 'til last Friday, everything seemed to be working just fine; we
can open, edit, update and save the files, and all other Eclipse file
manipulations seem to work as we hoped they would.
While working on a routine for adding markers to our files, I found
performance to be very bad. I created a "simple" project and linked
in the same file and saw no performance problem at all.
Running a network monitor while accessing the file in our own project
I saw this troubling behavior:
For each marker I added, the real file on the remote system was
opened, the first line of the file was read one.byte.at.a.time and
the file was then closed. This was repeated each time a new marker
was added, regardless of what line the marker was on, and regardless
of whether the file was open in an editor in Eclipse. As you might
imagine, this is painfully slow.
Performing the same operation on the same file open in a simple
project, I saw no network I/O whatsoever.
What in the world have I done to produce this bizarre behavior?
Where do I start looking?
--
Bert Hyman | Unisys - Roseville MN
bert.hyman@unisys.com | (651) 635-7791 | net2: 524-7791
|
|
|
|
|
|
|
|
| Re: Pathological Performance Problem with MarkerUtilities [message #287437 is a reply to message #287280] |
Wed, 29 June 2005 19:47  |
| Eclipse User |
|
|
|
Originally posted by: bob.objfac.com
It's still pretty awful.
Bob
Bert Hyman wrote:
> bob@objfac.com (Bob Foster) wrote in
> news:d9q5pj$ogb$1@news.eclipse.org:
>
>
>>Whatever else you do, please file a bug report against CDT. I'm
>>sure they'd like to know they're doing something so silly.
>
>
> On further investigation, it's not quite as bad as I thought at
> first.
>
> This binary check is only performed on files the CDT doesn't
> recognize as "its own".
>
> I'm toying with the idea of extending cdt.core.CFileTypeAssociation
> to declare all of our file types as honorary C source files. But,
> who knows what horrible side effects ->that would have.
>
>
>>Bert Hyman wrote:
>>
>>>wharley@bea.com (Walter Harley) wrote in
>>>news:d9p6sl$i6g$1@news.eclipse.org:
>>>
>>>
>>>
>>>>"Bert Hyman" <bert.hyman@unisys.com> wrote in message
>>>>news:Xns968253140E186VeebleFetzer@206.191.52.34...
>>>>
>>>>
>>>>>[...]
>>>>>For each marker I added, the real file on the remote system was
>>>>>opened, the first line of the file was read one.byte.at.a.time
>>>>>and the file was then closed. [...]
>>>>
>>>>Sounds like the sort of behavior that would happen if something
>>>>were trying to decide whether the file were binary or text? Maybe
>>>>that's a clue, dunno.
>>>
>>>
>>>That was it.
>>>
>>>We had attached the C Nature (org.eclipse.cdt.core.cnature) to our
>>>project so that anybody editing a C program file would get the
>>>benefit of the C outline.
>>>
>>>Unfortunately the CDT attaches a resource change listener which
>>>looks at the target file on every resource change event (adding a
>>>marker being one) and reads the first few bytes of the file to see
>>>if it's binary.
>>>
>>>So, we're currently weighing the benefit of supplying the C
>>>outline vs. the cost of opening/reading/closing the file on each
>>>and every marker. Or maybe some other way to stop the check on
>>>resource changes.
>>>
>>>This does suggest that people doing C development on non-local
>>>files might see some unexpected network traffic.
>
>
|
|
|
Powered by
FUDForum. Page generated in 0.03752 seconds
Home