On 07.09.2010 15:42, Hyrum K. Wright wrote:
> On Thu, Sep 2, 2010 at 2:46 PM, Mark Phippard <markphip_at_gmail.com> wrote:
>> On Thu, Sep 2, 2010 at 3:17 PM, Mark Phippard <markphip_at_gmail.com> wrote:
>>> I would not be so sure. When you are dealing with a GUI, adding a
>>> handful of milliseconds to something that is going to be done
>>> thousands of times can add up to less responsiveness.
>> I did some micro-benchmarks and the URI class does not perform too
>> badly -- although it is clearly slower. I did a loop to construct a
>> million objects and see how long it took:
>>
>> String class: 0.417
>> URI class: 3.968
>>
>> I then took the loop and added a call to a method that took a String
>> and just did a couple of simple checks of the String to make sure the
>> compiler was not optimizing away any problems. That gives:
>>
>> String class: 0.455
>> URI class: 4.003
>>
>> That said, in this example, if this were someone retrieving History
>> entries that would be 4 more seconds added to the UI wait. Granted it
>> might have been a minute or more to get these million entries from the
>> server, but it is still added time.
> While I don't agree with your reasoning, I've reverted r992041 in r993356.
I'm far from being an avid Java hacker, but I've been down the
String-vs.-File-and-URL road a couple times myself. While using the
appropriate types gives on a warm feeling about the code being more
bullet-proof, that actually isn't so true; and the downsides -- i.e.,
more API endpoints and less performance -- are not trivial.
I think the main reason for this is that File and URL are not very well
thought out, and despite all the improvements in newer versions of the
VM, youre still doubling the number of objects you create for every
string that you use. I blame heap fragmentation.
-- Brane
Received on 2010-09-07 17:39:12 CEST