Comparison between igraph and networkx

Skip to first unread message

Gustav Delius

Feb 27, 2009, 4:29:04 AM2/27/09
to networkx-discuss
Is there somewhere a summary of the relative merits of python-igraph
( and networkx?

I know that networkx particularly stresses that nodes and edges can be
arbitrary objects and igraph stresses its speed. But then networkx
also appears to be designed for handling large graphs and igraph also
allows properties to be attached to nodes and edges. So where are the
real differences?

Are there benchmark results measuring the performance on large

Also interesting would be a table summarizing which package includes
which algorithms.


Feb 27, 2009, 8:10:10 AM2/27/09
to networkx-discuss
Gustav, I also had to do a comparison of networkx and igraph. I really
like both projects and think they are both suitable for many
overlapping problems. I did some simple benchmarks an found that
igraph would out-perform networkx for simple metrics for larger
graphs; for example on some test graphs networkx took 8x as long to
calculate betweenness centrality. This makes sense as it is built in C
and the Python part is simply an interface to the underlying data
structures. Although, networkx had some features that igraph did not
have for some time; for example using weights in certain calculations.
Both communities are strong and both have really good project leaders
who are involved and responsive. Both are under active development as
well. In all, I really don't see there being an issue with using both
libraries. They both import and export in GraphML, so applying both
wouldn't be a big deal. I also really like the idea that there are 2
great libraries under active development because I can validate
results from one library with the other.



Feb 27, 2009, 8:12:36 AM2/27/09
to networkx-discuss
Oh, and also, I use the latest launchpad repository for igraph 0.6 to
get the latest features such as weights in centrality calculations.

Conrad Lee

Feb 27, 2009, 8:42:49 AM2/27/09
to networkx-discuss
I also made this comparison about 9 months ago.

Some difference I could point to:
  • iGraph has some community detection algorithms implemented, while NetworkX does not. 
  • iGraph's GraphML exporter included a more complete implementation of the GraphML specification, meaning that if you have a graph with all sorts of things labeled and weighted, it might be easier to export all this data into GraphML with iGraph.

Another difference between the two packages (and the reason I prefer NetworkX), is that NetworkX is well-documented, and has a fairly active community that can answer questions.  I found that the python version of iGraph was not very well documented.  Also, NetworkX is written more in python than iGraph.  If you are using the python version of iGraph, then you will usually not be able to read the source code in python--you will just run into a binding.

As Chris noted, using both packages should not be too difficult.

Conrad Lee

2009/2/27 Gustav Delius <>

Gustav Delius

Feb 28, 2009, 3:22:44 AM2/28/09
to networkx-discuss
Thank you very much for all the replies.

The advice to simply use both packages and where they both implement
an algorithm to use them to validate each other is very good.

I can confirm that both packages have lively user communities and very
dedicated developers who respond very quickly to queries.

I think the deficit in the documentation for the igraph package is
about to be remedied. I have seen the draft for the new tutorial for
the igraph python package and it was very helpful.


On Feb 27, 2:42 pm, Conrad Lee <> wrote:
> I also made this comparison about 9 months ago.
> Some difference I could point to:
>    - iGraph has some community detection algorithms implemented, while
>    NetworkX does not.
>    - iGraph's GraphML exporter included a more complete implementation of


Feb 28, 2009, 11:45:43 AM2/28/09
to networkx-discuss
If the speed aspect on NetworkX is in regard to graph layouts, the
latest svn (1157 tested) has some major improvements to large graph
performance. I measured a 15000% improvement (150x faster) bringing a
154 hour spring layout graph (16432 nodes, 17599 edges, 50 iterations)
to only 1 hour.

- Jeff
Reply all
Reply to author
0 new messages