NTrees.dll from Beta in Gamma, Issues

[lasal]

Hi guys,
i’m trying to use beta’s NTree.dll in Gamma, and Gen2 is counting up constantly.
Every time Gen2 counts up the patch freezes for a frame.
Probably i’m doing something wrong in the way i’m implementing it.
Any help would be great to have this beauty back in vvvv.

QuadTree.zip (23.2 KB)

[catweasel]

Kdtree.vl (34.0 KB) this is using the nuget kdtree. Its literally just a test to see if I could get anything to work for a possible project that didn’t go any further. It may or may not help.

GitHub - codeandcats/KdTree: A fast, generic, multi-dimensional Binary Search...

[lasal]

Thank you, i’ve tried already this nuget and it looks quite powerfull, but in the end i didn’t use it due its complexity.
I really like how simple the NTrees nodes work for realtime uses.

[bjoern]

Have you seen this?:
https://discourse.vvvv.org/t/are-there-any-spatial-data-structures-suited-for-vl

[lasal]

Bjoern, it looks great.
I have to start to think more about implementing algorithms than just reusing old Beta plugins.
With Gamma it’s much easier to build this kind of things.

Thanks for the pointer

[lasal]

In any case, the Ntree C# implementation is much faster than the patched one, independently from the drawing part.

[bjoern]

@lasal

In any case, the Ntree C# implementation is much faster than the patched one

I guess the explanation @Elias gave in the following thread also applies here:

VL.ForceDirected

The ticks can be compared directly - both represent µs. Just did a quick comparison and for N = 200, it’s ~900µs in beta vs ~2200µs in gamma. Reason is that the emitted code when running inside the editor is not as good as it could be. To name a few things which are different: A class in VL comes with one level of indirection (proxy and target) in order to quickly exchange them in the object graph (hotswap) - in this case we pay for that one a lot I wager as it affects the inequality check, th…

[lasal]

Not fully understand the reasons but thanks.

[gregsn]

It’s noteworthy that all libraries/packages nowadays - in vvvv gamma 5.0 previews - get pre-compiled by default. Pre-compiled == optimized.

To make vvvv gamma believe something is a package, the minimum requirement is to put it into a subfolder of vl-libs and name the subfolder like the document.

For developing & debugging the package you’d specify it as an editable package, for profiling & usage of the package you’d remove it from the list of editable packages.

---

Also the overhead for editable patches reduced since that quote from elias. The system got more light-weight regarding hotswap & the pressure on the garbage collector. But still there is a gap in performance between the optimized & precompiled vs. the inspectable & editable version.

[lasal]

I assume this can be also applicable to the exported apps, in that case there is no need to create a library pack.

[gregsn]

Sure. Exported apps are always optimized.