-
-
Notifications
You must be signed in to change notification settings - Fork 30
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
add benchmark script #214
add benchmark script #214
Conversation
It would be nice to get this in quickly to help with other PRs |
Thank you for your work for benchmarking graph convolutional layers. Not only the scale of graph is important, but also the edge number does matter. A graph usually contains less edges. For example, there are N nodes in a graph and the total possible edges are E = N(N+1)/2. Maybe a graph has 0.5 E edges, even less to 0.1 E edges. For a benchmark script, I think it is good to have kwargs for
Actually, I have no much idea about this.
Either adjacency matrix or other format, it should be transformed into normalized Laplacian matrix. The specialized method can be support of normalized Laplacian matrix for each format. |
Most natural networks are better modeled by an average degree which is constant or scales very weakly with |
20c812d
to
2b3e766
Compare
Benchmarking on erdos-renyi exposed another bug: |
Can we merge this? |
I would merge this first, but I think it is better to benchmark the conversion function |
Adding a script doing some basic benchmarking, in order to track performance changes as the library evolves.
I selected for testing the GCNLayer and the GraphConv layers as representatives of the algebraic and the message passing approaches respectively. Edit: Also added GATConv.
The benchmarks are on random graphs of small and up to moderate size (10 to 10k nodes).
Different graph storage types are tested (adjacency list, dense adjacency matrix, sparse adjacency matrix, LightGraphs.SimpleGraph).
These are the results on
my laptopa server, which I'm also committing as a referenceA few notes:
Quite surprisingly, the most performant graph type seems to be the LightGraphs's one, with several orders of magnitude better performances with GCNConv. Since GCNConv calls
adjacency_matrix
, that's a problem (for the other graph types) that should be easily fixed by providing better specialized methods.This is the comparison between
lightgraph
and other storage types