ESC-POS-.NET
ESC-POS-.NET copied to clipboard
Slow print after upgrade
A user reported slow prints (SerialPrinter) after updating to 2.0. Is there some new setting I need to define? Note: Previous version was 1.4.0, so 1.6.0 was skipped. Thanks
I found the reason: https://github.com/lukevp/ESC-POS-.NET/blob/a5e3fb8f2ad027dd80d90ea4b7886ecd9c79f3f4/ESCPOS_NET/Printers/BasePrinter.cs#L100 Since our data is sent line by line, this delay slows printing down dramatically.
Few more info about this change. It was introduced at https://github.com/lukevp/ESC-POS-.NET/commit/9a68c53354beabc6593627649398d3759b9320ab and there was a Delay of 50 ms before in WriteLongRunningTask method, but in a different line.

So the said commit actually moved it up, and doubled the waiting
Yes and the 50 ms delay got introduced with 32fae5e8 but never got published with any version it seems. v1.6.0 and 1.4.0 (the two most recent versions before 2.0) use the same synchronous code: https://github.com/lukevp/ESC-POS-.NET/blob/ec3283954b0b19f99db33a82cadbfb5d915c10c5/ESCPOS_NET/Printers/BasePrinter.cs#L97-L122
@lukevp do you know why there was a double in the delays?
From commit description is says Refactor delays in main loop so that it's delayed even if things are null
@igorocampos @neon-dev I'll take a look this weekend and factor this in to the process. Sorry for the issues! I versioned it up to 2.0 since there were major changes to the networking and threading code in this release. Thanks for the PR @neon-dev, I'll probably take in the fix and tweak it slightly. The purpose of the sleeps overall is so that each read/write thread doesn't busy loop (since they are in a tight while loop that never ends, it will peg a CPU core at 100% if there is no deferring or async actions taking place). If there is actually work to be done, there shouldn't be a need for a delay. I'll provide more comments on the PR when I review.