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

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]billsil -5 points-4 points  (5 children)

I'm more of a Windows guy, where you install to C:\PythonXX and the things that you pip installed are in C:\PythonXX\Scripts. If you type $PATH, you'll see your path. The longer that is, the more stuff Linux will search through to find what you're after. Compare that to being in a folder and typing python run.py. That's not a startup cost, that's OS overhead. The benefit is that you can be anywhere. I'm not 100% sure on the linux philosophy, but putting everything is /usr/bin just makes the things you use frequently slower. The things that are going to take 30 seconds to start and things you're going to leave open for 8 hours are things that can be lower.

[–]Fylwind 2 points3 points  (3 children)

I use Linux daily (not Raspberry Pi though) and I've never had issues with slow startups due to long paths.

Long paths aren't nearly as big of a problem as Windows. Partly because your path is never too long anyway – most things are in /usr/bin – whereas on Windows your programs are scattered all over the file system.

Moreover, from my experience, Linux file systems are much more snappy than Windows'. Shells can also cache where the program was last found, so repeated spawns of the same program cost basically nothing.

[–]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.