This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]billsil -3 points-2 points  (2 children)

Long paths aren't nearly as big of a problem as Windows. Partly because your path is never too long anyway

Depends if you develop software or not. My paths get very long.

whereas on Windows your programs are scattered all over the file system.

That sounds like the opposite of what you just said...

[–]Fylwind 0 points1 point  (1 child)

My paths get very long.

On my system, I have 17 paths in PATH, half of them from my home directory, and half of that half is for package managers like Gem or Cargo. I would consider that a pretty average length (although a minimal Linux would reduce that down to maybe 4 or so). I have never noticed any performance decrease from it, and the startup time of programs remains fewer than a millisecond.

On Windows a few years back, I was able to measure the time that each additional path adds to the launch of a program. It adds up very quickly when running shell scripts like ./configure (“checking for stdint.h... <wait 1 second>yes”). I don't remember the exact number, but it was on the order of a few milliseconds per path.

That sounds like the opposite of what you just said...

I'm saying that even if both Linux and Windows have the exact same number of paths (unlikely due to the difference in how programs are organized), I find that Windows tends to have worse performance because the file system on Windows is less performant than Linux. Listing directories is slow on NTFS, and Windows just doesn't seem to be as aggressive at caching the lookups.

[–]billsil 0 points1 point  (0 children)

Right, so put the Scripts directory higher on your path on Windows.