[haiku-commits] Re: haiku: hrev47984 - src/kits/locale src/servers/mail src/kits/tracker headers/os/locale src/add-ons/mail_daemon/inbound_filters/notifier

  • From: Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Thu, 09 Oct 2014 11:35:35 +0200

Am 09/10/2014 11:17, schrieb Adrien Destugues:
It still needs locking, no matter how rare.

Why would it need any locking?

If Tracker formats its date column a thousand times, it should not have to
lock for that at all. That's the use case you have to optimize for.
It currently creates one BDateTimeFormat instance and locks it, for each
date it formats. So we are already at the worst case here.

Moreover, BDateTimeFormat currently doesn't cache the ICU object used to
format dates, instead it is created on the fly each time the Format
method is called. So even if the BDateTimeFormat object was reused,
there wouldn't be much of a performance win.

Well, that's exactly what I'm saying: this should be corrected.

In all the places where I started using it in Haiku, the format is used
to format a single string at a time. I made the BMessageFormat instances
static so they are shared between windows using the same format. This
makes it possible to translate and parse the format string only once in
application lifetime (or only at locale changes).

Getting a translated string isn't exactly expensive. It's just a hash lookup.
Allocating memory, locking, etc. -- that is expensive, however.

However, with this scheme the format is shared between windows, and it
needs the locking. I expect this to not be a problem because the lock
won't be held for long, and the more time consuming parts of the work
(translating and parsing) are done only once.

Lock contention is only of minimal concern here; the locking itself is not for free either.

Bye,
   Axel.


Other related posts: