nano time

[clipperhouse]

Hi! This package looks promising.

I noticed your mention of fast time lookups and happened across this comment in the stdlib source when I wanted something similar.

So I implemented a version of the idea that is regular Go code, no unsafe: https://github.com/clipperhouse/ntime. May be of interest.

[samber]

Hey @clipperhouse

I appreciate your suggestion. I did not know that time.Since only uses monotonic time.

After a quick benchmark, I figured out it is 1ns slower. I definitely see benefit in code quality, but not in terms of performance. If anybody faces an issue with go:linkname in the future, please uncomment the following code and open a pull-request: https://github.com/samber/hot/blob/main/internal/time.go#L17

Happy to be part of the "hall of shame" 😅

[clipperhouse]

Hehe, cool, it just happened to be a rabbit hole I went down recently. Cheers.

[samber]

I will keep this issue open ;)

[clipperhouse]

Not on topic, but have you looked at sync.Map instead of using regular maps + mutex? It’s worked out well for me over here, especially when parallel: https://github.com/clipperhouse/rate/blob/main/benchmarks/README.md

[samber]

The composition patterns does not allow me to use sync.Map. Many use cases don't need locks.

If map is not performing well (i'm sure it's not, actually), I think we should make a change at the storage layer (in lru, lfu...).

Is it the wrong link you pasted above ?

[clipperhouse]

Cool. No, correct link, I was just intending to show that the parallel benchmarks are pretty fast.