Optimisation tactics - JSONata and State Machines

Hi

Dismissive ? alaSQL :smiley:

As knollary mentionned, it is a tradeoff of memory footprint, which is totally relevant ...

Battery performance wise jspath seems to offer versatility in optimisation.
But I got your feeling , functionnal progamming is elegant and a bit more secure than loop/branch, as long as it remain readable.

Sorry to wake up this thread ( almost closed )... I find out that JMEspath is shipped with node-red ( in the tree dependancies )...

Why nobody is using in it ? Isn't it much faster than jsonata ?

Probably because nobody else knows about it? None of us knew about JSONata either until the bods from IBM made it available to Node-RED.

There are hundreds of thousands of software modules - nobody knows them all and unless they are brought to our attention somehow, they remain obscure.

Also, all the talk of performance, while important for some, is of little relevance to many people using Node-RED. After all, if you were chasing performance, you would most likely be using Rust or Go.

Node-RED is a general purpose, low-code development and prototyping platform. It is here to make life easy for certain tasks. Performance is nice but not necessarily the be-all-and-end-all.

If JMEspath is good, then please do write a suitable node for it so that more people make use of it.

4 Likes

Hi,

Your comment is weird , how, where and why I use Node-Red is not subject to any discussion nor your own feeling nor experiences.

Performances is not a taboo subject as it is addressing to objective, battery life and bottleneck ( that lead to security problem )

As node-Red is a LR1 ( even with Queuemanager added ), performance should be a the 2nd matter once prototyped is done.

This diagnostic is shared among users of node-red , hence the success to of {unsafe-fonction} and the future coming {wasm-fonction}

Now as for JMEspath is good or not, that the whole point of the my question, since it is provided natively by Node-Red as well as JSONata.

Knollary already answered the question anyway ... from a point of view of unit test. But experience differ from our context as bottlenech can lead also to memory short supply.

Delay a flow will always lead to 2 problems , full CPU usage and memory crunch ( aka failing cache usage )

Anyway thanks for your time, I implemented a unsafe-fonction instead .

Why not be productive and contribute if you have some valuable know-how that this community and the future of Node-RED can benefit from? Being just destructive doesn't lead to anything good and certainly doesn't get much attention

1 Like

So if you don't want feedback, don't come to an open forum. I'm as free to say things as you are to ignore them. If you come to a discussion forum on Node-RED and ask a question, why and how you do things will certainly be discussed.

But in fact, I made no such comment about "how, where and why" you use Node-RED and it is unfortunate that you took it as such.

I gave an honest and open answer to your question. You seem to have taken it personally for some reason I can't fathom.

Subject closed as it isn't really helpful any more.

2 Likes