-
-
Notifications
You must be signed in to change notification settings - Fork 5.8k
[refactor] mailIssueCommentToParticipants #10478
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
0f78df4
to
9faf2e3
Compare
blocked by #10475 (if this is merged first a backport would be harder ...) |
I don't know. I carefully considered maps for this when I did it. Every time you access a map entry a hash function is executed and possibly a bucket must be allocated. Maps are slower to populate than slices. IMHO the current implementation is faster because it checks the map only one time per item after it is allocated with the required size. Especially in the 90% of the cases where the list is quite short. I've even did some benchmarks, I believe. I could be looking at this all wrong, though. 😅 |
e71d683
to
0754971
Compare
we get rid of https://github.com/go-gitea/gitea/pull/10478/files#diff-959cf0e72f197b979a8047af5f475157L113-L119 witch is an impruvement in my opinion ... but how did you make the benchmarks? |
Those two loops run through the data exactly one time; you may think they go over the same items several times, but they don't. A As for testing, I don't recall exactly, but there's only one way I'd do it, and it's programming loops with static data and timing them running in the 100,000 of times. The database must be excluded from the benchmarks because it's a common part of and the slowest by several orders of magnitude, of course. |
so if map dont add speed to it, I'll close this ... ? |
I don't know, others might have a different opinion than me. Or consider your code better for other reasons (e.g. clarity). |
this got it's change |
utilize map