Node red array of objects and cpu workload efficiency query

I'm struggling to understand how to format and use objects and keep things efficient.
I come from an embedded C background.

In my node red home automation implementation I have a global array of objects, one per 'thing'. The things may be anything from a lightswitch to a heating zone to a weather object. There are currently around 100 'things' and eventually it will have maybe 200-300.

I work on a thing from the array by using
let myThing = global.get("thingsStatus["+ thingId + "]").
and then individual properties eg. myThing.disabled

I have a common object format for most simple things and it has maybe 20 variables. Some things - such as heating or weather are much more complex and may add a further 10-15 variables.

I have done this by creating an optional 'extraobject' for the complex things. The extraobject takes a different form according to the type - weather/heating etc.
eg let windSpeed = myThing.extraobject.windSpeed

This all works but is prone to error when developing when I forget the property is part of the extra.I think I have made a rod for my back!

Q1.Would it be any less efficient to put all the properties for every thing type as the first level in the ting object?
This would mean that every item in the array had possibly dozens of properties that are meaningless.
Eg a lightswitch would have a windspeed property.

Q2. Is there a better way of having an array of objects where there are several different structures for the different object types?


Hi @coppo23

JavaScript does not have strict typing of objects. So it is perfectly okay for each object in your array to have a completely different set of properties to the next.

Each object may have 20 'common' properties, and then whatever additional properties it's particular type of thing requires.

So to answer you questions - it wouldn't be any less efficient for each object to have all of its properties at the top level. It would not mean that every item in the array has dozens of meaningless properties. They only have the properties you chose to set on them.

Thanks – that helpful. I’ll take a backup and make the change and see what happens.

Behind the scenes – can you explain how the Java engine know how to pull a specific variable from object[1] when object[2] has a variable of the same name, alongside several other variables that don’t exist in object[1]?

This bit of logic is behind my flawed thinking that all objects in an array probably need to be the same structure for efficiency. (It comes from my C background and pointers logic understanding.)


Firstly, I am certain you meant JavaScript (big difference when you go hunting for tutorials and info) :wink:

So the object "stored" in the array is its own entity with its own structure and properties. In fact, the array just holds a reference (pointer) to the "real" object (somewhere in memory).

The fact object[1] has a member property named .fred and object[2] has a property named .fred is besides the point, the array elements point to individual objects (so they can have the same or different properties - it doesn't even have to be an object - it could be an integer or string or ...)

In JavaScript, an array is a hashtable Object type so the interpreter doesn't need to keep track of physical memory. Changing the value of an element wont affect other elements as they are not stored in contiguous memory.

Thanks. I think I get it. (I'm perhaps being too concerned with what happens under the hood and trying to second guess what's happening!)

Yes, there is a very large gulf between the world of C/C++ and JavaScript and other "sensible" scripting languages :grinning:

You don't have to take care of all the minute details yourself since JavaScript is virtually always going to do that for you (what other reason would there be to use a language like this).

Having said that, it does make a lot of sense when creating structures like the one you've outlined to keep to a fairly fixed schema if you can. Treat a JavaScript object a bit like a database with each top-level entity being the rows and the content of those entities being the columns and you won't get too confused (of course, there are many other data structures you might want - this is only one way of thinking about things). Doing that makes processing a LOT easier. It also reduces your cognitive overload when thinking your way around any logic.

In fact, I try to keep my larger objects to a schema that I can also replicate pretty well in MQTT topics. That way, if (usually when) I want to have the data in memory (the object) AND want to use the event handling that comes with MQTT, I can do so using the same (or at least very similar) data structures.