Skip to content

Large performance improvement to GRG modification#135

Merged
dcdehaas merged 1 commit intomainfrom
add_muts_improve
May 5, 2026
Merged

Large performance improvement to GRG modification#135
dcdehaas merged 1 commit intomainfrom
add_muts_improve

Conversation

@dcdehaas
Copy link
Copy Markdown
Member

@dcdehaas dcdehaas commented May 5, 2026

Previously there were two performance problems with modifying GRG:

  1. The Mutations were hard deleted from a std::vector, which resulted in an O(N) copy of data every remove_mutation()
  2. The adding of a new Mutation flagged the mutation-to-node mapping to be resorted again on the next read access. This is overly aggressive IF AND ONLY IF you are adding Mutations to newly added nodes, then it is trivial to keep the mapping in the right sorted order by just appending to it.

Previously there were two performance problems with modifying GRG:
1. The Mutations were hard deleted from a std::vector, which
   resulted in an O(N) copy of data every remove_mutation()
2. The adding of a new Mutation flagged the mutation-to-node
   mapping to be resorted again on the next read access. This is
   overly aggressive IF AND ONLY IF you are adding Mutations to
   newly added nodes, then it is trivial to keep the mapping in
   the right sorted order by just appending to it.
@dcdehaas dcdehaas merged commit b46adb1 into main May 5, 2026
3 checks passed
@dcdehaas dcdehaas deleted the add_muts_improve branch May 5, 2026 20:36
AAce3 pushed a commit to CornellHPC/grgl that referenced this pull request May 7, 2026
Previously there were two performance problems with modifying GRG:
1. The Mutations were hard deleted from a std::vector, which
   resulted in an O(N) copy of data every remove_mutation()
2. The adding of a new Mutation flagged the mutation-to-node
   mapping to be resorted again on the next read access. This is
   overly aggressive IF AND ONLY IF you are adding Mutations to
   newly added nodes, then it is trivial to keep the mapping in
   the right sorted order by just appending to it.
AAce3 pushed a commit to CornellHPC/grgl that referenced this pull request May 7, 2026
Previously there were two performance problems with modifying GRG:
1. The Mutations were hard deleted from a std::vector, which
   resulted in an O(N) copy of data every remove_mutation()
2. The adding of a new Mutation flagged the mutation-to-node
   mapping to be resorted again on the next read access. This is
   overly aggressive IF AND ONLY IF you are adding Mutations to
   newly added nodes, then it is trivial to keep the mapping in
   the right sorted order by just appending to it.
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.

1 participant