Better performance

[kaatinga]

I see that we have several issues related to performance. I would like to help with this, like to increase performance :) who can help me to go through the current solution?

[swithek]

It seems there are only two issues mentioning potential performance improvements: #92 and #93. I'm not sure it's possible to implement the changes proposed in #92 because Get() depends on normal mutex locking when extending the TTL of an item. Of course, this feature is optional and can be disabled, but that would mean that we would need to determine which type of lock to use based on that option and I'm not sure whether that's the best way to address this (though I might think otherwise when I see the implementation).

[kaatinga]

Is there nothing besides the #92 and #93 on mind? I can look at #93

[swithek]

It might also be a good idea to expand the list of benchmark tests so that we could see how these performance improvements affect everything.

[gozeloglu]

Yes, you are right. Get depends on ttl update. Maybe the MGetWithoutTouchingOnHit (or something similar name) method can be implemented. It will be worked when disableTouchOnHit = true. If it is false, the MGetWithoutTouchingOnHit returns nil or error.

[KyleSanderson]

It seems there are only two issues mentioning potential performance improvements: #92 and #93. I'm not sure it's possible to implement the changes proposed in #92 because Get() depends on normal mutex locking when extending the TTL of an item. Of course, this feature is optional and can be disabled, but that would mean that we would need to determine which type of lock to use based on that option and I'm not sure whether that's the best way to address this (though I might think otherwise when I see the implementation).

This is an incredible overhead that I don't think has been fully exposed to you. regex compilation used to dominate my profiles, now it's the expiration queue which is ironic, hilarious, and "what, really" all at the same time.

Are you not seeing the same thing? There has to be a better way to handle this (a ticker and just updating the items under a mutex) would be better in this context. Is there a better way to handle this?

[swithek]

It would be nice if you could share your configuration options, data volume, and use case @KyleSanderson. It's hard to understand the full picture without that.

This is an incredible overhead that I don't think has been fully exposed to you.

That's why issues and discussions exist, we improve the package based on that.

Is there a better way to handle this?

Always. Suggestions and PRs are more than welcome, but please refrain from snarky comments, they help no one.

[ReneKroon]

An additional change could be an atomic per item CAS (compare and swap) data structure as backing store. Better than sharding, which is an O(1) solution. Op ma 5 jun. 2023 08:06 schreef Gökhan Özeloğlu ***@***.***>:

…

Yes, you are right. Get depends on ttl update. Maybe the MGetWithoutTouchingOnHit method can be implemented. It will be worked when disableTouchOnHit = true. If it is false, the MGetWithoutTouchingOnHit returns nil or error. — Reply to this email directly, view it on GitHub <#105 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAW5D6ARGCDDUOW3CQ3UDATXJVZPTANCNFSM6AAAAAAYLOGWJI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>