Bug 92563 - [content assist] Warm code assist performance for many types
Summary: [content assist] Warm code assist performance for many types
Status: RESOLVED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Text (show other bugs)
Version: 3.1   Edit
Hardware: PC All
: P3 normal (vote)
Target Milestone: 3.1 M7   Edit
Assignee: JDT-Text-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: performance
Depends on:
Blocks: 91494
  Show dependency tree
 
Reported: 2005-04-25 07:01 EDT by Tobias Widmer CLA
Modified: 2005-04-27 09:44 EDT (History)
0 users

See Also:

Attachments
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 Tobias Widmer CLA 2005-04-25 07:01:10 EDT 
I20050420-1200 + JDT UI Head

Steps to reproduce:
- Execute scenario as in bug 91494

-> ContentAssistant#computeCompletionProposals takes 890 ms
-> 740 ms of this are spent in StringBuffer#<init>

Reason: String#valueOf is called 3 times per type proposal
Additionally, package name, type name, completion and image descriptor are 
eagerly created.

In conjunction with virtual tables, this information should also be lazily 
computed.
Comment 1 Tom Hofmann CLA 2005-04-26 05:10:49 EDT 
added JavaCompletionProposal2 and subclasses which all just wrap jdt.core's
CompletionProposal and compute all information lazily.

Note that the display string is still created early due to sorting - added a
getSortString which is overridden by JavaTypeCompletionProposal2 with the hope
that the sort string computation may be less expensive than the display string.

Awaiting comments before closing.
Comment 2 Tobias Widmer CLA 2005-04-26 06:45:42 EDT 
The performance is significantly improved in the warm case:

I20050420-1200 + JDT UI Head

ContentAssistant#computeCompletionProposals takes 190 ms
using virtual tables and lazy compuation
Comment 3 Tom Hofmann CLA 2005-04-27 09:44:19 EDT 
comment 2 is good news - closing as fixed.