You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Implementing alternatives on mld (#3905, #4047) I used a couple of local stdlib containers which all use the global allocator to grow their internal capacity. Other routing algorithms do the same: for example the ch alternatives algorithm uses stdlib vectors, sets, etc.
Most of the time these stdlib containers are small - for example to store a couple thousands boundary nodes - and are temporary in nature getting created and destroyed over and over again.
We should hook in a thread-local stack allocator (similar to how we use thread-local heaps in the SearchEngineData) to handle small and repeated requests fast(er) and automatically grows.
Implementing alternatives on mld (#3905, #4047) I used a couple of local stdlib containers which all use the global allocator to grow their internal capacity. Other routing algorithms do the same: for example the ch alternatives algorithm uses stdlib vectors, sets, etc.
Most of the time these stdlib containers are small - for example to store a couple thousands boundary nodes - and are temporary in nature getting created and destroyed over and over again.
We should hook in a thread-local stack allocator (similar to how we use thread-local heaps in the
SearchEngineData
) to handle small and repeated requests fast(er) and automatically grows.Here's Hinnant's stack alloc we could use for this: http://howardhinnant.github.io/stack_alloc.html
Note: especially in the context of alternatives we should give the unpacking cache a try, too: #3835
The text was updated successfully, but these errors were encountered: