In every way possible.

I would like to skin alive the H1B mouthbreather who wrote this retarded
code.

Scenario:

Moving large files (6GB-7GB) from internal drive to external drive,
source and destination both compressed (NTFS compression).

System bogs down, showing hours to move files and moving at sub 3MB/sec
speeds.

Solution:

Clearly something is humping the I/O bus into submission. Track it down
using Task Manager and Resource Manager to one of the ubiquitous
catchcall svchost processes (thanks Microsoft for just shoving tasks
into the same process parent). Notice that while my copy process (both
robocopy and explorer equally slow) is moving data very slowly, the damn
svchost (LocalServiceNetworkRestricted) is reading the same file I am
writing *from the destination drive* at 250MB/min rate. Turns out it is
this shitheaded SuperFetch process.

So, for some reason, as the copy process writes the file to the
destination drive, SuperFetch is reading this same file from the
destination drive, absolutely saturating the I/O process. Thanks,
retarded service.

I'd also like to thank the asshats at Microsoft for naming the
SuperFetch service SysMain. That's right - SysMain. What in the ^%$&?
Not Fetch, SuperF, SFetch, or any other logical iteration, no, we need
my task/service enumeration as CRYPTIC as effing possible, to waste
minutes of my life (that I am trying to get back by killing this
service) by making it obtusely named.

As SOON as I stopped this service, my robocopy stopped acting like a
stillborn earthworm and actually starting cranking at 10 times the
former speed.

Hopefully, someone else wondering WHAT IN THE NAME OF SWEET BABY JESUS
IS GOING ON trying to simply copy files and wondering why it would be
faster to use a floppy intermediary drive may stumble upon this post and
rejoice.

Venger

backdrop wrote:
> Venger wrote:
>
> Dont be hasty, its not superfetch since I have tested many machines and
> have never seen such behavior.
> Superfetch works fine when transferring files... its probably your
> antivirus or some other program clashing with superfetch
> You could always disable it from the services list...
> start > type: services.msc and press enter

Ahem -

Yes, it is Superfetch. When I disable the service, the file transfers
immediately speed up to expected levels. When I re-enable the service,
the transfers immediately bog down. Additionally, the file and activity
is shown under resource monitor using the Superfetch parent process.

So, yes, it is.

It is not antivirus, since I do not run it. It is not Windows Defender,
since I do not run it. It is not Quake, Notepad, Lotus Notes, Print
Shop, Minesweeper, nor any other program. It is, indeed, Superfetch. In
fact, you can google and see others too have had problems with
Superfetch causing slow transfers.

It is indeed now disabled, and my file transfers are speedy and back to
normal.

Venger

"Venger" <(E-Mail Removed)> wrote in message
news:48aBl.23596$(E-Mail Removed)...
>
> It is not antivirus, since I do not run it.

Err if you don't run an antivirus, how do you know this is not an infection?

--
Asking a question?
Please tell us the version of the application you are asking about,
your OS, Service Pack level
and the FULL contents of any error message(s)

Gordon wrote:
> "Venger" <(E-Mail Removed)> wrote in message
> news:48aBl.23596$(E-Mail Removed)...
>>
>> It is not antivirus, since I do not run it.
>
> Err if you don't run an antivirus, how do you know this is not an
> infection?

Seriously? Please tell me you do not perform technical support for a living.

If you'd have actually read the original post, you'd know how...

Usenet. Why do I bother?

Venger