You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@fluo.apache.org by keith-turner <gi...@git.apache.org> on 2016/11/14 15:03:36 UTC
[GitHub] incubator-fluo issue #800: Investigate caching String to Bytes conversions a...
GitHub user keith-turner opened an issue:
https://github.com/apache/incubator-fluo/issues/800
Investigate caching String to Bytes conversions and visa versa
Since String and Bytes are both immutable, it may be worthwhile to cache conversion from one to the other. The following are some thoughts on possible implementations.
* Per thread cache w/o synchronization
* Global cache with synchronization
* Hybrid per thread/global cache
* Single threaded short lived per operation/per transaction caches.
----
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-fluo issue #800: Investigate caching String to Bytes conversions a...
Posted by keith-turner <gi...@git.apache.org>.
Github user keith-turner commented on the issue:
https://github.com/apache/incubator-fluo/issues/800
In #804 I did some very narrow caching. This caching is only at a per transaction level and in some cases only per a transactions operation.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] incubator-fluo issue #800: Investigate caching String to Bytes conversions a...
Posted by ctubbsii <gi...@git.apache.org>.
Github user ctubbsii commented on the issue:
https://github.com/apache/incubator-fluo/issues/800
Accumulo's client code has suffered from excessive caching of objects globally/statically in the JVM, all outside the user's control. If a caching feature is introduced, the user should have control over the size and lifecycle of the cache, to learn from Accumulo's lessons.
Of the options, I think the short-lived cache is most appealing. But, if it's user-provided, they could selectively re-use the same cache for many operations.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---