Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is work in progress. It could potentially be merged already, but I am opening this PR mostly to get some comments on the approach taken here.
This introduces a new package
subject
, which holds code that is to a large extent copied fromserver/sublist.go
. Eventually the code this was copied from should not any longer be needed and can then be removed. The idea of using a separate package is that this allows to hide the internals from direct access. This will make it much easier to refactor these internals later.The new package introduces the type
Subject
which holds the string representation of a subject together with its tokenized form. By using this type throughout the server code we can avoid tokenizing the same subject string over and over again. At least for some use cases this seems to be happening. I profiled the NATS server and I can show you profiles wheretokenizeSubjectIntoSlice()
is the function where most CPU cycles are spent.The PR has two commits, the first introduces the new type, the second commit shows how it can be used. To really benefit from the new
Subject
type it would also have to be used insublist.go
,memstore,go
andfilestore,go
. Basically it should be used all over the place, everywhere a subject is used. This would become a large change and I would only want to invest time into it if the NATS developers agree with the approach and embrace it.Please feel free to also point out bugs or problematic implementation details if you spot them. But most of all I am interested in hearing your opinion on the approach in general and whether you believe it is feasible and worthwhile.