[jira] Commented: (WINK-114) Cache parsed Accept header content where possible

["Michael Elman (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/WINK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12733533#action_12733533 ] 

Michael Elman commented on WINK-114:
------------------------------------

I see that both of you put the result of the StringUtils.fastSplit(value, ",") method to cache. Does it really take a lot of time?
To tell the truth, it's the first time I pay attention to this code, I think we should try first use precompiled pattern for the split. May be this with improve performance well enough to avoid the cache?
I'll attach a patch.

Regarding the cache limit: using WeakHashMap with Weak/SoftReferences should be preferred, so the objects will be available for garbage collection.

Regarding putting cache on TLS: I think it misses the point, since it will be available only on the same thread. Usually cache is designed to be resused by multiple threads.

One last thing: I think that this issue should be moved to 0.2

> Cache parsed Accept header content where possible
> -------------------------------------------------
>
>                 Key: WINK-114
>                 URL: https://issues.apache.org/jira/browse/WINK-114
>             Project: Wink
>          Issue Type: Improvement
>          Components: Common
>    Affects Versions: 0.1
>            Reporter: Nick Gallardo
>             Fix For: 0.1
>
>         Attachments: WINK-114-ThreadLocal.patch, WINK-114.patch
>
>
> AcceptHeaderDelete.fromString() is called for every invocation.  This drives calls to string splits and some regex tools that start to show up in profiles as taking up a notable amount of time.  Since the content for the Accept headers will remain within a fairly bounded set, we can cache the parsed content and improve performance.
> Here's a patch with a simple solution.  Really I think there's a better way to do this.  Presumably, there are other headers where the same thing applies.  We can handle those on an individual basis or we can come up with something more generic that can be used by all HeaderDelegates.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.