NotFoundException slowing this down by lots...

Hello!

I’ve worked pretty hard on speeding up my barcode scanner as much as I could. You can see a snippet of my code to crop the video feed, this has divided by 3 the processing time here!

https://github.com/zxing-js/library/issues/305

Another big point seems to be the NotFoundException which is a ts-custom-error. Using chrome inspection, I have took a sample of 3128 ms while scanning. Of those 3128 ms, 2241ms are using for creating those exceptions.

1026ms by the NotFoundException constructor 1185ms by the fixStack method called by that constructor.

I am not sure if native Errors would fix the issue, make it worse or better. But I am sure there is something better to do in this field. One would argue that errors shouldn’t be flying at high velocity like they are in this library. They are meant to be used when something went wrong, while here we simply expect it to happen quite often and does not mean something went wrong.

My guess is that using native Errors would help as Error.captureStackTrace would not be used every time (I doubt this is very useful for this kind of exception).

Another approach (that feels a bit hacky) would be to keep sending the same instance of NotFoundException. The idea is that the call stack would be the same anyways since it is called from a setTimeout, the stack is new. The only one that has a better stack is the first one thrown as it starts from the setup promise fulfill. Throwing the same exception again and again poses no real risk, we could freeze it just in case. This method would benefit from saving the time to create the new Error object which is very time consuming when done that many times.

My third suggestion would be to get rid of the throwing mechanic to prefer returning a null/false/empty value when a code is not found.

In case you wonder: I was on Chrome 83, with a 640x480 webcam displaying on a 375x812 sized debug screen. And this setup code:

      const config = new Map();
      config.set(ZXing.DecodeHintType.TRY_HARDER, true);
      config.set(ZXing.DecodeHintType.POSSIBLE_FORMATS, [/* ZXing.BarcodeFormat.EAN_8, */ZXing.BarcodeFormat.EAN_13]);

      this.codeReader = new ZXing.BrowserMultiFormatReader(config);
      this.codeReader.timeBetweenDecodingAttempts = 10;

[kenlyon]

I think that the amount of exception logging here is way over the top. It might be useful in some kind of verbose troubleshooting mode, but for normal production use, I don’t want my console being flooded with “exceptions” just because the program hasn’t yet detected a barcode in the camera image.

Could we consider changing this to some kind of optional setting? I would suggest that all five places where you use console.log() within a catch block should be conditional.

If you’re concerned about backwards compatibility, you could make the default behaviour the current and have to opt in to hide the logging. (Although my preference would be the opposite. I can’t imagine those errors are useful.)

[cmawhorter]

the most important part of OPs post was kinda glossed over:

ts-custom-error […] My guess is that using native Errors would help as Error.captureStackTrace would not be used every time (I doubt this is very useful for this kind of exception).

FWICT, it’d be pretty simple to remove capturing stack from the ts-custom-error file and just copy that file here sans fixStack call. nothing fancy is happening there.