feat: implement quicker backend/posix walk algorithm#1889
Conversation
8bef309 to
f0a19c2
Compare
|
@tonyipm I added a benchmark test in here, and got the following results (but didnt run many times, so these may not be statistically significant):
Can you try running the tests, or adding to the benchmarks to see if this really is speeding up the cases in question. Also, we should consider if this is slowing down any cases that we might need to address. |
|
tested again with some larger directories, these are relative to current main:
|
f0a19c2 to
8e42852
Compare
|
Thanks Ben I will take a look - in my own performance testing I found it consistently faster than the old algo and where performance was similar I ran a profile and found nearly all the elapsed time was in os.ReadDir. I will see if I can run up your perf tests and profile them. |
I didn't do extensive testing, but just a few cases of "large" directories vs fan out into multiple directories. I should probably fire up some tests with really large directories since thats the real case we are trying to solve here. Under a million files seems too fast on my system for any useful analysis. |
|
@tonyipm I wanted to make sure to revisit this PR. I think the speed up in the WalkFlatPaged and WalkWithMarker test may be worth landing this. I was curious if you had done any more testing and have any further results? |
820be45 to
d35229b
Compare
|
Thanks for the update Ben. I have done a lot of performance testing with this for our product workload, concentrating on the wide and deep directory structures that our customers have, and I find it consistently faster for those workloads. These cases have run times in seconds and minutes rather than ms and microseconds, and the improvement gets significantly greater the wider / deeper the directory. Thanks for bringing this into the main product code, this will make things a lot easier for us! |
d35229b to
cf67d63
Compare
|
I found another regression that i added a fix for in this. I need to do a little more testing to make sure nothing else missed here. |
3609882 to
80dba22
Compare
Rewrite the posix Walk implementation to avoid the extra ReadDir per directory that was noted as a TODO in the old code. The new algorithm holds all traversal state in a walkState struct and uses processDir to interleave sibling entries in correct S3 lexicographic order without a second syscall. Key changes: prefix optimisation: jump directly into the deepest matching directory rather than scanning from the root on every call marker short-circuit: skip entire subtrees that are lexically before the marker, making paginated listing faster Co-authored-by: Ben McClelland <ben.mcclelland@versity.com>
80dba22 to
33917ad
Compare
|
@tonyipm I think I have all the issues resolved that I could find in this latest version now. Do you want to do a final review of these changes? Also, I added a bunch of tests based on my regression and new issue testing. |
Rewrite the posix Walk implementation to avoid the extra ReadDir per directory that was noted as a TODO in the old code. The new algorithm holds all traversal state in a walkState struct and uses processDir to interleave sibling entries in correct S3 lexicographic order without a second syscall.
Key changes:
prefix optimisation: jump directly into the deepest matching directory rather than scanning from the root on every call
marker short-circuit: skip entire subtrees that are lexically before the marker, making paginated listing faster
Fixes #1845
Fixes #1855