# KDTree super inefficient

**URL:** https://discourse.flucoma.org/t/kdtree-super-inefficient/628
**Category:** Toolbox2 Related Bugs
**Created:** [August 5, 2020, 1:20am UTC](https://discourse.flucoma.org/t/kdtree-super-inefficient/628 "2020-08-05T01:20:43Z")
**Posts on this page:** 1
**Showing post:** 3

<div class="post-metadata">

### Author: ![weefuzzy](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/weefuzzy/32/362_2.png) [@weefuzzy](https://discourse.flucoma.org/u/weefuzzy)
#### Post date: [August 5, 2020, 9:25am UTC](https://discourse.flucoma.org/t/kdtree-super-inefficient/628/3 "2020-08-05T09:25:18Z")

</div>

There is a quiescent overhead with all the objects,

For NRT objects it got improved somewhat by me a couple of days ago because I noticed we were updating and constraining the parameters every vector rather than just when a trigger came in.

For RT objects (which is now most of the things that are causing you woe) here and in [FluidMLPRegressor killing sound on a server](https://discourse.flucoma.org/t/fluidmlpregressor-killing-sound-on-a-server/627)) it’s less straightforward. I’ll have a look to see if

1. For these classes, the parameter updates can also be made conditional (not so sure)
2. Whether the parameter updating code itself can be made less greedy. The problem is parsing strings and arrays.

---

_[View the full topic](https://discourse.flucoma.org/t/kdtree-super-inefficient/628)._