developit
Make loop stop when it doesn't have any more obj to check
With this change, if you have and object like { foo: "bar" } and you do dlv(obj, 'foo.bar.foobar.0.whatever') it will run twice instead of 5 times.
I have objects that are 20 degrees deep in a very performance sensitive app and this saves me quite a few loops
The bundlesize is a little bigger now.
Wrote 130 B: dlv.js.gz
99 B: dlv.js.br
Wrote 130 B: dlv.es.js.gz
100 B: dlv.es.js.br
Wrote 208 B: dlv.umd.js.gz
175 B: dlv.umd.js.br
Maybe https://github.com/developit/dlv/pull/32#issuecomment-495304365 can be considered as well, I'm just not sure on the performance downsides of for vs .some
The bundlesize is a little bigger now, but IMO the performance gain is worth it.
Why? No-op spinning loop shouldn't have any significant impact (and might be even optimised away altogether).
The bundlesize is a little bigger now, but IMO the performance gain is worth it.
Why? No-op spinning loop shouldn't have any significant impact (and might be even optimized away altogether).
The objects I'm handling are quite big and in some of my functions, this change saves me hundreds of loop, object manipulation, and conditional checks.
For small objects indeed there is no gain. But for bigger ones that's not the case
this change saves me hundreds of loop, object manipulation, and conditional checks
Did you benchmark it? That's the only way to prove that change is actually worth it, it's not like JavaScript is interpreted literally. (also FWIW there is no object manipulation involved after the first condition hit)
https://esbench.com/bench/5ce7f6624cd7e6009ef62543
This is a very small change. I have objects double that size running in loops of hundreds. In my case you can increase this performance gain by 100x if you zoom out to my application
In my case you can increase this performance gain by 100x if you zoom out to my application
How so? Proportions shouldn't change from either number of times you run it or size of the object (only from level of nesting maybe).
Moreover, if your application is doing anything else besides property access, they're likely to become completely negligible compared to other operations.
Finally, if you do care about performance more than the size (which is the main target of this helper AFAIK), then, as mentioned before, you probably shouldn't use dynamic property access in the first place and instead use optional chaining operator instead (e.g. via Babel plugin - https://www.npmjs.com/package/babel-plugin-transform-optional-chaining):
In my case you can increase this performance gain by 100x if you zoom out to my application
How so? Proportions shouldn't change from either number of times you run it or size of the object (only from level of nesting maybe).
I call the function several times, not only once. So it's 100x because I call it 100x. That's why the if you zoom out to my application part
Moreover, if your application is doing anything else besides property access, they're likely to become completely negligible compared to other operations.
What do you mean?
Finally, if you do care about performance more than the size (which is the main target of this helper AFAIK), then, as mentioned before, you probably shouldn't use dynamic property access in the first place and instead use optional chaining operator instead (e.g. via Babel plugin - https://www.npmjs.com/package/babel-plugin-transform-optional-chaining):
I was searching for something I could use both frontend and backend and I don't use babel in my nodejs apps. But maybe is something that I need to look at since the performance difference is that much.
I assumed that since the transpiler adds code for other parts, the performance improvement that I gain over one thing would be lost by other features.
I will actually look into the babel plugin. Thanks for the suggestion. Can you send me the benchmark link so I can check the setup? I'm curious about that.