-
Notifications
You must be signed in to change notification settings - Fork 16
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
Enable sorting for walk_ports #60
base: master
Are you sure you want to change the base?
Conversation
As it stands this can't be merged. The additional complexity introduces allocations into port walking which is used in a very small number of spots for RT port reflection (I think in at least one of the MIDI mapper/automations code implementations). Seeing the relative complexity here I think it might make sense to implement the sort at the level of the schema dumping on zyn's side. |
They should all have |
True, but you know about how many headaches that creates with stoat. |
@fundamental What about using a stack allocation for that vector? We know the size already, and stack allocations are common in rtosc. Is the heap allocation of |
Allocations are the primary concern with added complexity being a smaller secondary concern. stack allocation is a possibility for subports_sorted, though std::stable_sort is not guaranteed to be alloc free, and C++ lambdas will generate allocations if there are captured variables. |
Blocked by zynaddsubfx/zynaddsubfx#197 .
You probably meant harmless stack allocations, right? |
Last I checked (which to be fair was a good few years back) it was heap allocations. The design choice was made at some level to simplify how lambdas are routinely packed into std::function<> objects. My info could be out of date though. |
Tested with zyn: The sorted schemata before and after the PR are equal (except of the proposed whitespace fix).