Ubergraph - request for volunteers to benchmark alternative implementation

455 views
Skip to first unread message

Mark Engelberg

unread,
Aug 14, 2019, 7:09:02 AM8/14/19
to clojure
I have created a "specter" branch of ubergraph which uses the specter library for all nested map access and transformations. I believe this will speed up ubergraph, especially for adding and removing edges, but I would like it if some users of ubergraph would compare the performance of the specter branch against the 0.7.0 master branch on their graphs.

https://github.com/Engelberg/ubergraph/tree/specter  

If the speed improvement is enough to warrant the added dependency, I'll merge the specter branch into master.

Thanks.
Message has been deleted

Matthias Nehlsen

unread,
Aug 17, 2019, 3:00:35 PM8/17/19
to Clojure
Just tried it out and the improvements were substantial. I tried to add 94K nodes (journal entries) to a graph, most of which have multiple edges, and with 0.7.2 it took 137 seconds, whereas with the specter branch, it only took 92 seconds. Everything else worked fine as well. Thanks for this library, been working very well for me in https://github.com/matthias/meins.

Mark Engelberg

unread,
Aug 17, 2019, 5:14:03 PM8/17/19
to clojure
That's great news. Thanks for the report.

On Sat, Aug 17, 2019 at 7:59 AM Matthias Nehlsen <matthias...@gmail.com> wrote:
Just tried it out and the improvements were substantial. I tried to add 94K nodes (journal entries) to a graph, most of which have multiple edges, and with 0.7.2 it took 137 seconds, whereas with the specter branch, it only took 92 seconds. Everything else worked fine as well. Thanks for this library, been working very well for me in https:/github.com/matthias/meins.


On Wednesday, August 14, 2019 at 9:09:02 AM UTC+2, puzzler wrote:

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/clojure/bdfc451a-9108-4728-89f7-1a23263b15fd%40googlegroups.com.

Colin Taylor

unread,
Aug 17, 2019, 9:41:47 PM8/17/19
to Clojure
I didn't strip it down for a true benchmarking test and my use case is large but fairly sparsely connected graphs, but I get about 10% improvement.

Mark Engelberg

unread,
Aug 18, 2019, 4:30:09 AM8/18/19
to clojure
Thanks.

On Sat, Aug 17, 2019 at 2:41 PM Colin Taylor <colin....@gmail.com> wrote:
I didn't strip it down for a true benchmarking test and my use case is large but fairly sparsely connected graphs, but I get about 10% improvement.

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages