Re: [eclipse-dev] NLS.bind(...) vs MessageFormat.format(...)

[Aaron Digulla <digulla@xxxxxxxx>]

John Arthorne schrieb:

> The memory footprint has nothing to do with whether you use NLS#bind or 
> MessageFormat#format. The memory footprint reduction comes from using the 
> NLS mechanism of defining a Java file and a property file.  The savings 
> from using this can be significant for large applications (if you call 
> several MB of memory significant). More info here:
> 
> http://www.eclipse.org/eclipse/platform-core/documents/3.1/message_bundles.html
> 
> There is a speed difference between these methods, so for those who care 
> about speed it's still worth using even if you don't care about memory.

Usually, it's not worth to worry about a few MB of memory or a speed
difference below 20% (which is just not noticeable for the average
user). Reasoning:

- More complex code leads to more errors. If your code is more simple,
then you will have less errors. Since two APIs are more complex than
one, always prefer to use a single API. Tend towards the more simple API
 but avoid APIs which are too simple (i.e. which will cause trouble
later because you simply can't do something).

- If you're not tight on RAM or CPU power, thinking about saving a few
MB or a few seconds of processing time is a premature optimization and
those always lead to problems in the maintenance cycle.

Let me give you an example: I wrote some code in Groovy which created a
2MB HTML subtree. When I ran the code, it took 155s to see the result in
Internet Explorer. Since Groovy is about 2-3 times slower than pure Java
(or so I thought), I rewrote the clean Groovy code into a Java mess.
After that, I could display the result in 152s. Hooray! Less than 1%
saved! ;)

After finally getting myself to run a profiler, I got these figures:

- 5s spent in Groovy code (which includes ResultSet.next())
- 20s spent in database to fetch the data (i.e. the time after which the
query returned and I could start to process the rows)
- 130s spent in IE inside of "div.innerHTML = result". When I save the
HTML to a file and load that, it takes less than a second.

That is all of the time is lost in IE. Today, I have a big and ugly Java
class that is hard to maintain and the savings don't count since I fixed
the problem where it happens (in IE) and by rewriting the SQL query.

Morale: Never ever optimize code unless you have hard figures from a
profiler where the actual time is lost. And never ever even bother to
think about how much memory/CPU your code might need. Write it in a
clean way, then run it and if it doesn't perform, fix the few lines of
code which cause the trouble. Since you wrote them in a clean way, there
will be no problem to fix them.

Regards,

-- 
Aaron "Optimizer" Digulla a.k.a. Philmann Dark
"It's not the universe that's limited, it's our imagination.
Follow me and I'll show you something beyond the limits."
http://darkviews.blogspot.com/          http://www.pdark.de/