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
Subscription subject interning #819
Comments
We either copy or send to a socket any message (with subject) that is given to us, so internal to the library not sure this would help too much, but could be used above the NATS lib. |
I am talking about processMsg in Subscribe* methods where copy of string(subjectBytes) instantiated for each processed message |
Do we have any measurable results? |
I also started reusing Msg container utilising sync.Pool (since my application using fixed size messages) as a result gotten rid of allocations for subscriptions in my use case. I will check if there is any benchmarks I will be able to run them on processMsg. |
If it has a definitive impact I am all for that for sure. Thanks! |
@derekcollison What about this #824 ? |
Regarding message container reuse I am using smth like this and totally ok with it, because of fixed message sizes, have no idea how to adapt it to public use, maybe we need some ranges of messages size and achive messages depending on their size in different buckets, or utilize smth known for it. Also maybe some adapter factory in options to allow decide whether the pool .Get() should be used. or default New().(*Msg). var msgPool = &sync.Pool{
New: func() interface{} {
return new(Msg)
},
}
func (m *Msg) Release() {
m.Subject = ""
m.Reply = ""
m.Header = nil
m.Data = m.Data[:0]
m.Sub = nil
m.next = nil
m.barrier = nil
m.ackd = 0
msgPool.Put(m)
}
m := msgPool.Get().(*Msg)
if !nc.ps.msgCopied {
if cap(m.Data) < len(data) {
m.Data = m.Data[:cap(m.Data)]
m.Data = append(m.Data, make([]byte, len(data) - cap(m.Data))...)
copy(m.Data, data)
} else {
m.Data = m.Data[:len(data)]
copy(m.Data, data)
}
} else {
m.Data = data
}
for msg := range subChan {
process(msg)
msg.Release()
} |
Feature Request
Reduce allocation by interning subjects using predefined map of subjects or just by utilising intern.Bytes
Use Case:
Subscriptions
Proposed Change:
or some predefined map
Who Benefits From The Change(s)?
Users of subscriptions
The text was updated successfully, but these errors were encountered: