Bug 125136 - [perfs][index] Performance peak when saving a file
Summary: [perfs][index] Performance peak when saving a file
Status: VERIFIED WORKSFORME
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.2   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.6 M3   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-01-25 04:46 EST by Dirk Baeumer CLA
Modified: 2014-04-04 05:42 EDT (History)
5 users (show)

See Also:

Attachments
The HTML trace (4.93 KB, application/octet-stream)
2006-01-25 04:47 EST, Dirk Baeumer CLA 		no flags Details
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 Dirk Baeumer CLA 2006-01-25 04:46:55 EST 
After filing bug 125135 and disabling the CVS decorator I still noticed a CPU peek when saving a file where I added a single blank. Looking at the trace again shows that I spent ~1000ms IndexManager. I opended a separate bug for the 600 ms in ManifestConsistencyChecker.
Comment 1 Dirk Baeumer CLA 2006-01-25 04:47:36 EST 
Created attachment 33581 [details]
The HTML trace
Comment 2 Dirk Baeumer CLA 2006-01-25 04:50:18 EST 
The build id is: I20060119-0800
Comment 3 Olivier Thomann CLA 2009-06-25 15:19:00 EDT 
This is too old and latest performance tests didn't expose such a problem on 3.5.
Closing as WORKSFORME.
Comment 4 Dani Megert CLA 2009-06-26 01:42:38 EDT 
>This is too old
Agree it is old.

> and latest performance tests didn't expose such a problem on 3.5.
The sad thing about our performance tests story is that they have no memory i.e. once we go to the next build even a performance bug causing hours delay would appear green in the next release because the baseline is reset.

Given performance is always one of our high priorities I would feel better if this got measured before being closed. Frédéric, could you do that?
Comment 5 Frederic Fusier CLA 2009-06-26 03:55:33 EDT 
I'll have a look to this...
Comment 6 Frederic Fusier CLA 2009-09-29 10:57:38 EDT 
(In reply to comment #4)
> >This is too old
> Agree it is old.
> 
> > and latest performance tests didn't expose such a problem on 3.5.
> The sad thing about our performance tests story is that they have no memory
> i.e. once we go to the next build even a performance bug causing hours delay
> would appear green in the next release because the baseline is reset.
> 
> Given performance is always one of our high priorities I would feel better if
> this got measured before being closed. Frédéric, could you do that?

The performance results of 3.2.2 build shows a gain in indexing between 14% and 19%, so I guess that we cannot consider there's a real performance regression here

I cannot either reproduce the CPU hit while adding a blank in a file and saving it. Activating the indexer trace, I can see that it is activated while saving the file but as there's no CPU hit, I think that we can consider this bug as 'worksforme'...
Comment 7 Frederic Fusier CLA 2009-10-26 11:00:48 EDT 
Verified for 3.6M3 using build I20091026-2000