kevin

Hello 👋 I realise this is 3 years old... but just wondering if there was a reason not to go ahead with this? I was considering forking and implementing something...

Hey, thanks for getting back to me! Yeah I'm not sure either now that I think about it actually > So how would it work after the PR is already...

> expanding EdgeData to have multiple modes of indexing/caching each of which are lazily computed as required That's an interesting idea. So we would build the index automatically when `graph.neighbors`...

> I guess that's equivalent in my mind to EdgeData computing them when other_node_type is specified, since that'll happen if (and only if) it's being used by an algorithm that...

I think this now conflicts a lot with https://github.com/stellargraph/stellargraph/pull/1435 and the new speedups I'm getting are not as huuuuge compared to what's already landed in `develop`, so I might try...

Hmm maybe the benchmark test doesn't quite provide the full picture.. notebook seems to be much slower than 3x (been running random walks for ~2 hours)

> Hm, 2 hours with this PR or with `develop`? #1446 is related too. with develop. With this PR, the whole notebook runs within ~10 mins or so

Running it now 🏃

I tried making the metapath2vec benchmark larger by adding more node types and more edges - the speedups do seem to get larger as expected: ``` ------------------------------------------------------------------------------------------------------ benchmark: 2 tests...

I couldn't really figure out a nice way to resolve the conflict with https://github.com/stellargraph/stellargraph/pull/1463 so I ended up basically overwriting those changes... (sorry @kieranricardo !) Notably, the existing laziness from...