-
Notifications
You must be signed in to change notification settings - Fork 6
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
Accidental O(N^2) behaviour? #23
Comments
Is it just export? If you leave out |
Behaviour is the same without export. |
If I double the samples, I see 3.2x the number of cycles spent on a single 'test' instruction in |
On a filesystem with a very small number of files, I expect performance to be linear. On a filesystem very many files (e.g. one hypothetical extreme being that every sample will be in a never-seen-before file), then performance should be very close to O(n^2). This is because siblings are stored as a linked list. At some point siblings were stored as a hash table, however I swapped that out because keeping a hash table on every node had a significant overhead, and memory use seems to be the dominating side of performance pressure right now for typical filesystems. Maybe we can try something with less overhead but still better than linear, such as a red-black tree. |
Happy to provide test results if you want to experiment, but I don't consider this too important. |
@CyberShadow Do you want to close this one also or are you considering a tweak? |
I think it's actionable. |
This is somewhat academic since you clearly get very good resolution with a low number of samples, but maybe there are non-academic issues lurking you might be interested in.
I observe that if I double the samples, it takes approx 4x as long to generate an export. Is there some accidental N^2 complexity somewhere? I don't think this is necessary a big deal (so feel free to close), but thought you might like the data:
Note I'm using handwavy order-of-magnitude math but I might have expected the latter to take (5.3s x 4 = ) ~20s rather than ~40s.
X axis: # samples
Y axis: Time per sample in microseconds (i.e, it's getting more costly per sample)
The text was updated successfully, but these errors were encountered: