everything (in a more literal sense then just, Everything) can be slow with (disk) I/O

[therube]

everything (in a more literal sense then just, Everything) can be slow with (disk) I/O.

So I threw in 1385...

So I had an existing hash check (verify [with CHK]) ongoing...
That hash check was using all the "bandwidth" (I/O) to a USB flash drive attached HDD (30 MB/s).
(The check was also using "multiple threads", with a "thread" here meaning that it opened multiple "handles", 4 in my case, to 4 individual files, meaning that it was reading 4 files simultaneously.)
[Multiple threads, probably ?, makes no sense here, as I'm I/O bound ?]

-

opened 1385 & restored Session (manually)
(& then didn't pay attention - for a LONG while)
when i did look, maybe it was 5 of 9 windows (& unknown number of tabs) had
actually opened, & then, NONE (or a least the couple windows i actually looked at)
had any results, & 1 indicated (something or the other, didn't particularly pay attention)
maybe scanning or querying or ?

at that point i Paused a (CHK) hash verification i had ongoing (& it will be ongoing for a
LONG time) & with that pause, Everything /then/ (speedily) opened its remaining windows & proceeded
to correctly show the expected files within

& there was a LONG period of time between (in the order of 18+ minutes) since i had opened Everything,
initiated the Session Restore & then before i actually (looked &) noticed that i had yet to get any actual data
from that

(then I resumed the hash verification
of W:, as it is, so a steady 30 MB/s of I/O, CPU/RAM are negligible, but impacts on some aspects of
system operation are relatively, HUGE
- Everything & opening a file [on W:] in Vim, or in MPUI/MPlayer when advancing to the next song...
- CPU < 5%, RAM <46 MB peak/ws, ~190 virtual, so all of that is minimal)


- just noting - that an ongoing process may have a HUGE material impact on performance of another
process


reducing I/O priority to Very Low (Low didn't seem to effect a change) /smoothed out/ the I/O
"graph" - but did not actually affect I/O (dealing with 30MB/s [& this with 4 "threads" - handles,
actually, it was opening/reading 4 files simultaneously])
[though I'm not certain, but I suspect that "speed" (throughput) is relatively unaffected]

reducing (process, if you will) Priority (so different from I/O priority) to Below Normal
did not seem to have any affect on anything, so I returned that back to Normal (priority)

note that performance (ability for something to happen) seemed to only be affected - in certain
circumstances... like with playing music advancing to next song (which actually entails both a
GUI part, & a back-end player part, with the GUI sending the file name to open to the back-end,
& the b-e actually doing the open/play) didn't seem affected during "normal, consecutive playback",
but more like if you were to pause the player (so pausing, probably for some extended period of time, say an hour)
the GUI/player combo actually, it would finish the current song, then get "stuck" on opening the
next song (& after it did finally open it, subsequent song were then again, unaffected)

CrystalDiskInfo, while already open & running, while it (the CHK) had been running,
i was unable to actually bring its window, to front, until i lowered I/O level...

a "simple" rename on an I/O bound drive, caused Everything to go opaque
- setting (process) Priority to Below Normal level - made NO difference - still opaque
- & i'm not talking about a second or so, FAR more time then to come here & write this

setting *I/O* Priority to Very Low DOES help
that /seems/ to lessen I/O spikes, making I/O more consistent
(don't know if that actually affects "speed", though i'm /guessing/ it does not)


A different kind of slow, that seemed to be due to exhausted RAM & paging to disk, Slow to query after sitting for a few hours. (Though note in his later screenshot, he does have some decent I/O ongoing too [in addition to RAM paging].)


an old i5-3570k, 16 GB RAM, spinner disks, USB 2.O

[therube]

Filled up I/O breaks usage of Everything, or more generally, everything (potentially).

(Wasn't sure if I should have piggy-backed on the other post or not...
And this too was from some time back.)


opened 1385 & restored Session (manually)
(& then didn't pay attention - for a LONG while)
when i did look, maybe it was 5 of 9 windows, had
actually opened, & then, NONE (or a least the couple i actually looked at)
had any results, & 1 indicated (something or the other, didn't particularly pay attention)
maybe scanning or querying or ?

prior to opening/restoring Everything, I had a CHK Hash ongoing.

upon realizing what had happened (did not happen),
i Paused [using System Informer] the (CHK) hash verification i had going (& it will be ongoing for a LONG time)
& with that pause, Everything /then/ opened its remaining windows & proceeded
to correctly show the expected files within

there was a LONG period of time between (in the order of 18+ minutes) since i had opened Everything,
initiated the Session Restore & then before i actually noticed that i had yet to get any actual data
from that open

(i then Resumed the hash verification
of W:, as it was, running at a steady 30 MB/s of I/O - CPU/RAM are neglible,
but impacts on some aspects of system operation are relatively, HUGE
- Everything & opening a file [on W:] in Vim, in MPUI/MPlayer when advancing to the next song...
- CPU < 5%, RAM <46 MB peak/ws, ~190 MB virtual
CHK running in a multithreading mode, so reading 4 files simultaneously
which probably makes no sense as I/O is going to be the limiting factor...)

- just noting - that an ongoing process may have a HUGE material impact on performance of another
process

reducing I/O priority to Very Low (Low didn't seem to effect a change) /smoothed out/ the I/O
"graph" - but did not actually affect I/O
(dealing with 30MB/s [& this with 4 "threads" - handles, actually, it was opening/reading 4 files simultaneously])

[changing process Priority to Below Normal did not seem to have an effect, so i returned that back to
Normal]

note that performance (ability for something to happen) seemed to only be affected - in certain
circumstances... like with playing music advancing to next song (which actually entails both a
GUI part, & a back-end player part, with the b-e actually closing on song change, with the GUI
sending the file name to open to the b-e, & the b-e actually doing the open/play) didn't seem
affected during "normal, consecutive playback"

(it was more like if you were to pause the player, maybe it was Stop (which closing the b-e
engine, maybe time played in ? so pausing, probably for some extended period of time, say an hour,
the GUI/player combo actually, it would finish the current song, then get "stuck" on opening the
next song {& after it did finally open it, subsequent songs were then again, unaffected])

CrystalDiskInfo, also, while it had been running, prior to any of this, i was unable to actually bring
its window, to front, until i lowered I/O level...

a "simple" rename on an I/O bound drive, cause Everything to go opaque
- setting process Priority to Below Level, made NO difference - still opaque
- & i'm not talking about a second or so, FAR more time then to come here & write this!

setting *I/O* Priority to Very Low DOES help
that /seems/ to lessen I/O spikes, making I/O more consistent
(don't know if that actually affects "speed", though i'm /guessing/ it does not)

[void]

What type of drives and how are they connected? eg: USB/SATA/m.2

[therube]

(When I wrote above, I'd forgotten that I had previously posted, everything (in a more literal sense then just, Everything) can be slow with (disk) I/O.
[Merged.])


Anyhow, the CHK was running against a USB (2.0) external HDD (W:, Western Digital).