On 9 Jun 2010, at 15:52, galder(a)jboss.org wrote:
----- "Mircea Markus" <mircea.markus(a)jboss.com> wrote:
> On 9 Jun 2010, at 10:13, galder(a)redhat.com wrote:
>
>> Hi guys,
>>
>> This came to my mind while sleeping.
> You definitely over-geeked me!
>> While I was profiling the Hot Rod server, I noticed that some time
> (3%) was being used reading the string cache name from the wire and
> transforming it to UTF-8.
> How much of the time is being used to convert the byte[] to utf 8
> String? At least for writes we can use an cached byte[] rather than
> converting it each time.
About half. 1.5% reading the byte array and 1.5% converting it to UTF-8. The problem is
that I need to get a cache out of it, so somehow you need to map that byte[] to the cache
that it maps to. I have doubts whether creating a UTF-8 string and then getting a cache
out of it is worse than having to maintain a mapping between byte[] and the target cache.
yes, might be. In my case (client) this can be optimised by keeping the cache name
(String) as a cached byte[] so that I don't do the conversion on every HR operation,
but only once. I've created
https://jira.jboss.org/browse/ISPN-490
>>
>> Now, in the test I was acting against the default cache which we had
> established to be requests sent to "___defaultcache" would be
> considered to be directed to the default cache. However, I'm thinking
> that this is waste of space. We could make things even quicker when
> default cache is used by simply assuming that if the length of the
> String is 0, followed by nothing, then the default cache will be used.
> If a length other than 0 is passed, the String follows and we have to
> read it.
> +1
I've created:
https://jira.jboss.org/browse/ISPN-489
>>
>> WDYT?
>> --
>> Galder ZamarreƱo
>> Sr. Software Engineer
>> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev