Latest spdlog slows down shutdown

[joaomoreno]

	dispose(): void {
		let then = new Date().getTime();
		this.logger.flush();
		let now = new Date().getTime();
		console.log('FLUSH', now - then);
		then = now;
		this.logger.drop();
		now = new Date().getTime();
		console.log('DROP', now - then);
	}

cc @bpasero

[gabime]

@joaomoreno no need to do both flush and drop. spdlog does flush when dropped. This should reduce by half the wait time for dispose.

[joaomoreno]

@gabime Hey man! Thanks for checking up on us!

Yeah we found out about that recently, yet didn't adopt it. I'll give that a try. Is there any other thing that comes to mind which would make flush/drop slower from 0.14.0 to 0.16.3?

[gabime]

@flush in async mode might be slower indeed, since it waits for the queue te be empty(which itself takes up to 500ms even on empty queue)

possible fixes:

1. I think callng flush is not really needed in your case . If i understand correctly, vscode enables the periodic flush of 2 seconds in async mode anyway (which happens in the bg thread and doesnt block the caller).

2. I am willing to release an update for spdlog in which flush wont wait for the queue to be empty before returning. It will still be on by default to preserve back compatibly , but a flag or something will configure this.

3. Use sync mode - it is so fast that a human wont notice any difference anyway. It would also preserve resources, since in async mode, a dedicated thread is created per each logger (but then you need to take care of flushing, since no periodic flush exists in sync mode)

[joaomoreno]

flush in async mode might be slower indeed, since it waits for the queue te be empty(which itself takes up to 500ms even on empty queue)

So, what has changed since 0.14.0? Was flush() not waiting for the queue to be empty, before?

[gabime]

No, The wait was increased from 200ms to 500ms to reduce cpu usage (gabime/spdlog@b1be7b9#diff-3aed88857f9442521f921ff98e021e33)

[joaomoreno]

Oh I see!

[joaomoreno]

Removed the call to flush. Seems speedy again! I see drop taking anywhere from 25ms up to 439ms. This is fine as it doesn't seem to disturb any quit or reload perception.

Thanks for the help @gabime, no need to release any update.