mem: skip defer for performance #48
Conversation
|
How I wish that defer was faster. This seems fine. I remember Jason using that benchmark suite to compare perf numbers before. You may also be interested in running I'm curious: why will converting the structs to pointers make perf improvements? I recently made a largeish API change to remove allocations in the hot paths because it was adversely impacting perf. |
|
My mistake. My expectation is that by not allocating the metadata structs it'll speed it up a bit. |
| @@ -168,21 +168,27 @@ func (m *Message) NumSegments() int64 { | |||
| // Segment returns the segment with the given ID. | |||
| func (m *Message) Segment(id SegmentID) (*Segment, error) { | |||
| m.mu.Lock() | |||
| defer m.mu.Unlock() | |||
| var seg *Segment | |||
| if isInt32Bit() && id > maxInt32 { | |||
There was a problem hiding this comment.
nit: this case doesn't require the mutex
There was a problem hiding this comment.
You mean we can move m.mu.Lock() below this block correct?
|
Coming back to this:
That's exactly what I was looking for. Only just got around to reading that code. I also made a patch for the the serialization benchmarks repo. Here are the results: https://gist.github.com/abraithwaite/905555e81b35eca8d30987690dfc1220 Very nice! 👏 Edit: here's the patch, if you want to upstream. Otherwise I'd be happy to, but it's your work :-) https://gist.github.com/abraithwaite/93d6f0b6ed505a78d6686bff1850eb4a |
abraithwaite
force-pushed
the
performance
branch
from
cb4dff6 to
f8b915c
Compare
mem.go: skip defer for performance
|
Merged with some tweaks to critical sections. You should go ahead and upstream the benchmark changes. |
We're looking to move to go-capnproto2 from the original and we've been comparing the performance of the two using alecthomas' go serialization benchmark suite.
This is a minor patch which improves the speed moderately. We're still looking at options for increasing the speed. Most of them probably involve changing the go structs to pointers, if that's amenable to you.
Here's the performance comparison with and without this changeset:
https://gist.github.com/abraithwaite/a8876d351edf16bc052cd6b5acdaa330
I'm not sure why the svgs don't render nicely on gist though :-(