malxau
commented
3 years ago Well, the fastest way to speed it up:
C:\src\yoriperf>timethis oneyori.exe -nouser -c test.ys1
Elapsed time: 0:00:00.203
Child CPU time: 0:00:00.203
Child kernel time: 0:00:00.125
Child user time: 0:00:00.078
Tree CPU time: 0:00:00.203
Tree kernel time: 0:00:00.125
Tree user time: 0:00:00.078(ie., using oneyori for this is 40x faster.)
I learned a few horrifying things about Windows while developing Yori, but I think this issue is hitting at the worst: in Windows, CreatePipe will create a synchronous pipe, and there is no way to know if a synchronous pipe has data available because the expectation of the named pipe system is to wait until there is a blocking write and a blocking read at the same time, then shuttling the data across, then completing the requests. This is bad for two reasons: a) performance is terrible due to context switching so the named pipe system needed to add a buffer which undermines the reasoning here and b) processes can't wait on multiple things simultaneously, which makes it impossible to have a cancelable operation, and threads don't help since a worker thread can't check for data on the pipe and check for any communication from another thread.
So Yori did the best thing it could do. It spins waiting to see if it should cancel or if there's data in the pipe. It can't spin on the CPU (which would destroy performance) so there's a sleep between each spin to let the other process make progress. The length of the sleep increases progressively, because if no data has arrived in several seconds it's unlikely that it will arrive a microsecond later.
But this sequence trips up this logic badly. The first couple of processes make progress; the later processes observe no data is arriving and start sleeping for longer and longer; and when data arrives, they are waiting for tens of milliseconds before noticing that any data is available. This magnifies down the chain, because if one process waits pointlessly for 10 milliseconds everything behind it starts increasing the duration of their sleeps, so the next one waits pointlessly for 20 milliseconds, etc. Amusingly, doing this with oneyori is fast because it won't launch 36 things in parallel - it's executing one command at a time, so there's never a time when a reader is waiting for data for a long time.
I have a tweak for this logic to increase the length of the sleep more slowly, which helps in this scenario, but note this is not a free lunch. Every time the thread wakes up and does nothing, it's slowing down the rest of the system, including the thread that's supposed to write data into the pipe.
Anyway, this algorithm makes it 10x faster, and about half the time compared to the 36 line version, but it's still 4x slower than the serial oneyori version:
diff --git a/lib/lineread.c b/lib/lineread.c
index e985595..2b5271f 100644
--- a/lib/lineread.c
+++ b/lib/lineread.c
@@ -506,7 +506,11 @@ YoriLibReadLineToStringEx(
Sleep(DelayTime);
CumulativeDelay += DelayTime;
- DelayTime *= 2;
+ if (DelayTime < 10) {^M
+ DelayTime++;^M
+ } else {^M
+ DelayTime = DelayTime * 5 / 4;^M
+ }^M
if (DelayTime > 500) {
DelayTime = 500;
}
aleaksunder
Hello!
I understand everything has it's limits and not insist to get this into primary goal... this is just a remark!
I am seeing a sharp drop in performance using decent amount of stream input and output.
This is only for example but let's assume we have a text file with such content:
replace.txtSo in real life we have a text file encoded with non-english ASCII symbols.
And we need to replace all those 36 values with text and going to do so with following script with a lot of pipes:
replace.ys1All works... but: `timethis.exe yori -nouser -c YS "replace.ys1"
12 seconds certainly not a big deal but if process comes to real text file with normal contents speed degrades drastically...
The thing here is if we split those 36 REPL pipes into 36 different lines:
and do that again with: `timethis.exe yori -nouser -c YS "replace.ys1"
So despite there was 36 disk reads 72 encoding conversions and 36 disk writes it is 6 times faster than 1st variant... one problem here is we need to check an ERRORLEVEL after each of 36 lines to ensure that all was correctly.
And by the way in real life with 30 lines in script we get speed something around 5 seconds per file and with one line in script with 30 pipes speed drops to 30 seconds per file!
And this is not about
REPLonly... I've tried a lot of sequiental pipes around multipeICONVand it seems it degrades in the same way!So it is basically 6 times faster everywhere I've seen, tried this with
CMDYORIYORIMINandONEYORI... and the numbers always almost the same!And just for example tried this in
CMDwith externalfindstr.exe:So there is 128 pipes and nothing seems to degrade significantly... I am basically want to say that as I see this is not due to Windows piping mechanism!
Or maybe you can advice how to speed things up?
P.S. I'm so sorry to be so annoying =) I believe I am doing useful things for this project