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

IsDigraphHomomorphism is significantly slower for mutable graphs #318

Closed
jjonusas opened this issue May 4, 2020 · 9 comments
Closed

IsDigraphHomomorphism is significantly slower for mutable graphs #318

jjonusas opened this issue May 4, 2020 · 9 comments
Labels
bug A label for issues that are bugs performance A label for issues or PR related to performance resolved A label for issues that are resolved, but not yet closed for some reason.

Comments

@jjonusas
Copy link
Contributor

jjonusas commented May 4, 2020

gap> g := CompleteDigraph(100);;  
gap> g2 := DigraphMutableCopy(g);;
gap> IsDigraphHomomorphism(g, g, (1, 12));; time;
19
gap> IsDigraphHomomorphism(g2, g2, (1, 12));; time;
753
@james-d-mitchell
Copy link
Member

james-d-mitchell commented May 4, 2020

Thanks @jjonusas, it seems that the issue here is with OutNeighbours the output of which, maybe because OutNeighbours is an attribute, is copied every time it is called (9900 times in the code above). This can be fixed by making OutNeighbours a function instead of an attribute, must think a bit more about whether or not that’s a good idea.

@james-d-mitchell james-d-mitchell added bug A label for issues that are bugs performance A label for issues or PR related to performance labels May 4, 2020
@james-d-mitchell
Copy link
Member

If we do:

gap> for i in [1 .. 9900] do
> OutNeighbours(g);
> od;
gap> time;
2

but if we do:

gap> g := DigraphMutableCopy(g);
<mutable digraph with 100 vertices, 9900 edges>
gap> for i in [1 .. 9900] do
> OutNeighbours(g);
> od;
gap> time;
607

So, the only reason I can I think of not to make OutNeighbours a function, is that at present with OutNeighbours an attribute, the return value is immutable, and so too are each of the sublists it contains. If OutNeighbours becomes a function, then the return value is mutable, and so too are each of its sublists. Any thoughts @wilfwilson?

@james-d-mitchell
Copy link
Member

I'm fairly sure that if the return value of OutNeighbours is mutable, and it is changed outside of the relevant Digraphs functions (DigraphAddVertex etc), then the digraph will be corrupted, but obviously what @jjonusas reports is also bad

@wilfwilson
Copy link
Collaborator

It’s bad, but imo it’s also not really how mutable digraphs are intended to be used. The point of mutability is to make it cheaper to modify/build digraphs. But once you want to do really any kind of computation, you should make it immutable. That’s my initial gut feeling - but perhaps I’m missing something.

@jjonusas
Copy link
Contributor Author

jjonusas commented May 4, 2020

The reason I've encountered this is that ChromaticNumber makes a mutable copy of the graph, which would appear to go against the intended use.

@wilfwilson
Copy link
Collaborator

Ah! Good to know.

@james-d-mitchell
Copy link
Member

So, it looks to me that ChromaticNumber needs some work on this front. I could also "fix" IsDigraphHomomorphism for mutable digraphs, but I wonder if that's a good idea? Any thoughts?

@wilfwilson
Copy link
Collaborator

Sorry I didn't see this. I've not had any thoughts about this.

@james-d-mitchell james-d-mitchell added the resolved-pending-release A label for issues that have been resolved and that can be closed when a new version is released. label Mar 1, 2021
@wilfwilson wilfwilson added resolved A label for issues that are resolved, but not yet closed for some reason. and removed resolved-pending-release A label for issues that have been resolved and that can be closed when a new version is released. labels May 16, 2021
@wilfwilson
Copy link
Collaborator

Resolved in v1.4.1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A label for issues that are bugs performance A label for issues or PR related to performance resolved A label for issues that are resolved, but not yet closed for some reason.
Projects
None yet
Development

No branches or pull requests

3 participants