Skip to content
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

Do multiple passes of the groups example #318

Closed
wants to merge 1 commit into from

Conversation

AnyOldName3
Copy link
Contributor

This should reveal when allocators have degraded performance over time or when reusing previously-freed space.

If the groups example's main purpose is allocator benchmarking, then the new default value of three passes is sensible as it avoids the risk that reuse of freed space won't get benchmarked when the allocator is modified, but otherwise it may be sensible to change the default to a single pass.

This should reveal when allocators have degraded performance over time or when reusing previously-freed space.
@robertosfield
Copy link
Collaborator

Thumbs up on having a good test for this performance issue, I do wonder if this example is getting to test specific. Perhaps another example just focused on the mutlipass test would be better.

@robertosfield
Copy link
Collaborator

I have merged this PR as branch of vsgExamples: AnyOldName3-multipass-groups

When I run it against VSG master I see:

$ vsggroups 
using VsgVisitor
type : vsg::Group
numNodes : 5592405
numBytes : 212511376
average node size : 38
numNodesVisited : 55924050
construction time : 0.194289
traversal time : 0.125244
destruction time : 0.144473
total time : 0.464007

Nodes constructed per second : 2.87839e+07
Nodes visited per second     : 4.46519e+08
Nodes destructed per second : 3.87089e+07

using VsgVisitor
type : vsg::Group
numNodes : 5592405
numBytes : 212511376
average node size : 38
numNodesVisited : 55924050
construction time : 4.65186
traversal time : 0.13395
destruction time : 0.146522
total time : 4.93233

Nodes constructed per second : 1.20219e+06
Nodes visited per second     : 4.17499e+08
Nodes destructed per second : 3.81677e+07

using VsgVisitor
type : vsg::Group
numNodes : 5592405
numBytes : 212511376
average node size : 38
numNodesVisited : 55924050
construction time : 4.81207
traversal time : 0.12715
destruction time : 0.146463
total time : 5.08568

Nodes constructed per second : 1.16216e+06
Nodes visited per second     : 4.39828e+08
Nodes destructed per second : 3.81829e+07

average construction time : 3.2194
average traversal time : 0.128781
average destruction time : 0.145819
average total time : 3.49401

Average Nodes constructed per second : 1.73709e+06
Average Nodes visited per second     : 4.34255e+08
Average Nodes destructed per second : 3.83516e+07

Which looks like a 24 X slowdown of construction between the first and second passes. Ouch. Is this similar to what you are seeing with VSG master without your performance fix?

@AnyOldName3
Copy link
Contributor Author

Yep, 20-25x is what I'm typically seeing.

@robertosfield
Copy link
Collaborator

robertosfield commented Oct 17, 2024

I have stripped down and copied this vsggroups version to a new vsgreallocations example to make it clearer what is going on leaving the original vsggorups in place. I'll now close this PR as it's now redundant, the new example was merged with PR #327.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants