Re-implemented the Trie crow uses to match rules with URLs #166
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.
One of the parts I avoided documenting because of how complex it was.. Here I am digging into the deepest parts of it and making a better version.
With the poetic crap out of the way, Here's what the old version did and how I changed it.
OLD
rule_index
,param_childrens
, andchildren
.rule_index
is an integer to inform where a rule name ends.param_childrens
is an array of 5 integers, representing the 5 different parameter types (<int>
,<path>
etc..). if a child of the node is a parameter, its index (from the nodes list) is placed in the corresponding place in the array.CROW_LOG_DEBUG
adding its own line end, and the fact that the printing function was adding the level spaces and param in 2 different calls.NEW
rule_index
,key
,param
,children
rule_index
remains unchanged.key
was previously the string in children, is now part of the node itself.param
replacesparam_childrens
, being a single variable telling the parameter type of the node itself.children
a list of node pointers, replacing the map.The architectural changes were primarily giving the node more autonomy over data related to it, and fixing the optimization.
Performance wise, 2 different tests consistently showed the following:
10%
35%
as much memory for the same tree as the old one (pre optimization)10%
as much memory as the old implementation did. Proving that the optimization (at least when it comes to memory) actually works.20µs with 40µs jumps
and new:10µs
, so while it is a large gain percentange, it is very small in actual time.