RE: proposal for ICU tracing

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of 
> Carl W. Brown
> Sent: Monday, November 03, 2003 3:23 PM
> To: [email protected]
> Subject: RE: proposal for ICU tracing
> 
> Request #2 add a user pointer in the TLS that the application 
> can manage. Provide an API that makes the address of the 
> pointer available to the application at any time.  The 
> appliction must free and structures that it points to with 
> the pointer before freeing the TLS.

This is particularly important in Windows especially, since Windows does no automated cleanup of any sort. And the automated cleanup routines, in some POSIX implementations, is also broken or extremely limited. So in general, if Carl is suggesting that the application must manage TLS data, I'd agree. There are quite a few places where it can be applied with great success. But on the whole, the memory management aspect of TSS objects (in Win32 and POSIX APIs) is, in my opinion, really flawed and is its one short-coming. Users are left with manually managing the memory, or if they want more sophisticated memory management, they are left to writing their own native TSS implementation (it is not too difficult to write one yielding higher performance and scalability).

Cautionary Note: some platforms only support 64 thread keys. If ICU starts chewing up many keys, application developers may become disgruntled.

Additional side note, if the application pools threads, one could just let the objects dangle, and never deallocate.

> I believe that ultimately the addition of TLS support into 
> ICU could actually improve the performance.  For example it 
> could be used to reduce locale processing overhead.  ICU 
> spends a lot of processing checking and decomposing locale 
> information especially when you need both C and C++ locale 
> pairs.  You could save the C locale, a pointer to the C++ 
> locale object and the language, country and variant 
> components of the locale until a new locale value was passed. 
>  If the results were stored into TLS they could speed up ICU 
> processing more than the extra overhead for tracing.  I have 
> watched traces of ICU activity and believe that this would be 
> a significant performance enhancement that could be phased in 
> over a few releases.

I've been able to demonstrate a huge performance advantage in MATLAB by caching in thread specific storage a per thread converter pool. I've measured the time to create converters at as high as 30455 cycles (first converter ever created in a process), and on average around 2080 cycles (create time for the same converter type thereafter). For the same application, getting one from a thread specific converter pool, about 351 cycles. Creating pooled allocator APIs, for ICU objects of all sorts, can be a big win for ICU users.

- Bob