tigerquoll commented on PR #1117: URL: https://github.com/apache/yunikorn-core/pull/1117#issuecomment-5213935879
I would suggest some level of caution - Walk is faster for iteration because it directly returns the internal element slice of the b-tree node, bypassing the element by element iteration delivery function call - consider it a batch-oriented iteration call back that primary saves time because you get called once per node rather then once per element. So the time savings are proportional to how much getting a single function call overhead per leaf node saves versus the per-element Yunikorn processing overhead. This needs to be weighed up against risk of logic changes to your processing code - as using walk means you are no longer proposing a "drop-in" replacement for the old tree implementation. My understanding of Yunikorn processing loops is that they are reasonably heavy compared to function call overhead, thus the overall savings for this change would be minimal On the subject of being a "drop-in" replacement - I believe tidwall defaults to having it own internal lock (the read lock gets held for the entire scan/walk operation - write lock gets held for sortedNode access ), which should probably be turned off with the NoLocks: true option - Yunikorn-level locks should already adequately protect the structure from concurrent modification. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
