Bug 206423 - Optimization opportunity in DefaultProblemFactory
Summary: Optimization opportunity in DefaultProblemFactory
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.4   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.4 M4   Edit
Assignee: Maxime Daniel CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-16 02:46 EDT by Maxime Daniel CLA
Modified: 2007-12-11 07:00 EST (History)
3 users (show)

See Also:
kent_johnson: review+


Attachments
Fix proposal (4.89 KB, patch)
2007-10-26 05:46 EDT, Maxime Daniel CLA
no flags Details | Diff
Better fix + test cases that specifically address the weaknesses of the previous one (7.99 KB, patch)
2007-10-30 10:03 EDT, Maxime Daniel CLA
maxime_daniel: review?
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Maxime Daniel CLA 2007-10-16 02:46:54 EDT
Source based, v_819
The (needed) change added by Olivier to the fix for bug 122885 (I missed the dependency of String.replaceAll upon Java 1.4) made clear that getLocalizedMessage could be optimized, one aspect being to minimize the number of conversions between String and char[].
Comment 1 Maxime Daniel CLA 2007-10-26 05:46:53 EDT
Created attachment 81249 [details]
Fix proposal

This proposal does the following:
- work upon char[] as long as possible;
- add a convenience parseInt method to CharOperation that should optimize the most
  frequent case (index ranging from 0 to 9).

I decided against changing the loop structure, even if we test quite often output against null, and its complexity, because it needs multiple exit points indeed (hence unsure we could do much better without breaking it).

We may want to suppress messageWithNoDoubleQuotes and modify message in place instead. What do others think about this point?
Comment 2 Maxime Daniel CLA 2007-10-26 05:47:31 EDT
Kent, would you please have a look and let me know what you think?
Comment 3 Kent Johnson CLA 2007-10-29 13:39:21 EDT
char[] message = ((String) this.messageTemplates.get(...)).toCharArray();
if (message == null)


This won't work. The get() will answer null & blow up.

Same for the elaboration
Comment 4 Maxime Daniel CLA 2007-10-30 04:48:08 EDT
(In reply to comment #3)
> char[] message = ((String) this.messageTemplates.get(...)).toCharArray();
> if (message == null)
> 
> 
> This won't work. The get() will answer null & blow up.
> 
> Same for the elaboration
> 
You're right. Will improve this and try to add a test case that blows it up. If I get it well any failure here is due to point out a translation issue of some sort, or a mistake on our part in the messages files. Wander if we wouldn't be better off considering that this is abnormal and should result into an NPE anyway? The message we send is not NLSed, which is barely better than throwing an exception, right? Please let me know what you think.

Comment 5 Maxime Daniel CLA 2007-10-30 10:03:35 EDT
Created attachment 81581 [details]
Better fix + test cases that specifically address the weaknesses of the previous one

This new proposal sticks to the 'if null raise a message' policy that the previous patch inadvertently broke.
It also adds specific tests to visit the missing message template and elaboration template cases.
Last, I removed messageWithNoDoubleQuotes without breaking any existing test case.

Kent, would you please let me know what you think of this new proposal?
Comment 6 Maxime Daniel CLA 2007-11-07 04:46:47 EST
Released for 3.4 M4.
Comment 7 David Audel CLA 2007-12-11 07:00:32 EST
Verified for 3.4M4 using build I20071210-1800.