lodash“get”和“if else”子句之间的性能差异

Question

Let's say you have a typescript object, where any element can be undefined . If you want to access a heavily nested component, you have to do a lot of comparisons against undefined .

I wanted to compare two ways of doing this in terms of performance: regular if-else comparisons and the lodash function get .

I have found this beautiful tool called jsben were you can benchmark different pieces of js code. However, I fail to interpret the results correctly.

In this test , lodash get seems to be slightly faster. However, if I define my variable in the Setup block (as opposed to the Boilerplate code ), the if-else code is faster by a wide margin.

What is the proper way of benchmarking all this? How should I interpret the results? Is get so much slower that you can make argument in favour of if-else clauses, in spite of the very poor readability?

Answer 1

I think you're asking the wrong question.

First of all, if you're going to do performance micro-optimization (as opposed to, say, algorithmic optimization), you should really know whether the code in question is a bottleneck in your system. Fix the worst bottlenecks until your performance is fine, then stop worrying overmuch about it. I'd be quite surprised if variation between these ever amounted to more than a rounding error in a serious application. But I've been surprised before; hence the need to test .

Then, when it comes to the actual optimization, the two implementations are only slightly different in speed, in either configuration. But if you want to test the deep access to your object, it looks as though the second one is the correct way to think about it. It doesn't seem as though it should make much difference in relative speeds, but the first one puts the initialization code where it will be "executed before every block and is part of the benchmark." The second one puts it where "it will be run before every test, and is not part of the benchmark." Since you want to compare data access and not data initialization, this seems more appropriate.

Given this, there seems to be a very slight performance advantage to the families && families.Trump && families.Trump.members && ... technique. (Note: no if s or else s in sight here!)

But is it worth it? I would say not. The code is much, much uglier. I would not add a library such as lodash (or my favorite, Ramda ) just to use a function as simple as this, but if I was already using lodash I wouldn't hesitate to use the simpler code here. And I might import one from lodash or Ramda, or simply write my own otherwise, as it's fairly simple code.

That native code is going to be faster than more generic library code shouldn't be a surprise. It doesn't always happen, as sometimes libraries get to take shortcuts that the native engine cannot, but it's likely the norm. The reason to use these libraries rarely has to do with performance, but with writing more expressive code. Here the lodash version wins, hands-down.

Answer 2

What is the proper way of benchmarking all this?

Only benchmark the actual code you are comparing, move as much as possible outside of the tested block. Run every of the two pieces a few (hundred) thousand times, to average out the influence of other parts.

How should I interpret the results?

1) check if they are valid:

Do the results fit your expectation? If not, could there be a cause for that? Does the testcase replicate your actual usecase?

2) check if the result is relevant:

How does the time it takes compare to the actual time in your usecase? If your code takes 200ms to load, and both tests run in under ~1ms, your result doesnt matter. If you however try to optimize code that runs 60 times per second, 1ms is already a lot.

3) check if the result is worth the work

Often you have to do a lot of refactoring, or you have to type a lot, does the performance gain outweight the time you invest?

Is get so much slower that you can make argument in favour of if-else clauses, in spite of the very poor readability?

I'd say no. use _.get (unless you are planning to run that a few hundred times per second).