On Fri, Jun 26, 2015 at 10:05 PM, Dr Gregory Jefferis <[email protected]> wrote: > One thing I have noticed is that some of my functions (in CRAN package nat) > now run ~50x slower. I've traced this to a change in behaviour, where > functions like graph.dfs return vertex sequences rather than plain (integer) > vertex ids. subsetting those vertex sequences can be very slow. This can be > changed by the igraph_option return.vs.es=F (which incidentally does not > seem to be documented)
Undocumented, because it is dangerous. If you change it, it'll apply globally. I think if you change it now, you are probably safe, though, because most functions expect numbers instead of vertices. > Here is a (stupid) toy example: [...] > user system elapsed > 0.713 0.007 0.719 [...] > 0.001 0.000 0.001 [...] > But this means changing quite a bit of code and there are places where > similar issues cannot be so easily side-stepped. > > Two questions: > > 1. Is this slow down expected? Wow, I expected it to be slower, but not this much. I should have measured. > 2. As a package developer, is there any way to ensure I have the behaviour > of igraph_options(return.vs.es=F) when I import the igraph package (while > still giving other users the chance to set igraph_options(return.vs.es=T) > if that is what they want) ? Unfortunately not, AFAIK. These options are global. > As a comment, my feeling is that this behaviour should probably be > controlled both at a per function as well as a package option level. Yes, function specific arguments are good. You can set the option as a workaround now, I think. I'll speed this up in 1-2 weeks, and then everything should be fine again. G. [...] _______________________________________________ igraph-help mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/igraph-help
