tags:

views:

253

answers:

6
+2  Q: 

Which is faster??

is opening a large file once reading it completely once to list faster (or) opening smaller files whose total sum of size is equal to large file and loading smaller file into list manupalating one by one faster?

which is faster?? is the difference is time large enough to impact my program?? total time difference of lesser then of 30 sec is negligible for me

+2  A: 

Obviously one open and close is going to be faster than n opens and closes if you are reading the same amount of data. Plus, when reading a single file the I/O classes you use can take advantage of things like buffering, etc, which makes it even faster.

dcp
I think this is not *that* simple ... you forget we work on machine with: limited resources (i.e. RAM) and multiple processors.
PierreBdR
@PierreBdR - The question was a general question, not about how to efficiently process n files using parallel processing or other advanced alogrithms, etc. That is what I tried to answer, and I'm well aware of the fact that resources are limited on machines. I'm not sure why you have a problem with my answer.
dcp
A: 

Working with a single file is almost certainly going to be faster: you have to read the same amount of data in both cases, but when working with multiple files, you have that much more housekeeping operations slowing you down.

Additionally, you can read data from a single file at the maximum speed the disk can handle, using the disk buffer to the maximum etc., whereas with multiple files, the disk head does a lot more dancing jumping from file to file.

Tomislav Nakic-Alfirevic
+1  A: 

If you are reading the file sequentially from start until end, one open/close is faster than multiple open/close operations.

However keep in mind that if you need to do a lot of seeking in your 1 big file, then maybe storing separate files won't be slower in that case.

Also keep in mind that no matter which approach you are using, you shouldn't read the entire file in at once. Do it in chunks.

Brian R. Bondy
+6  A: 

It depends if your data fit in your available memory. If you need to resort to paging, or virtual memory, then opening a single giant file might become slower than opening more smaller files. This will be even more true if the computation you need to make creates intermediate variables that won't fit in the physical RAM either.

So, as long as the file is not that big, one opening will be faster, but if this is not true, then many opening may be faster.

At last, note that if you can do many opening, you might be able to do them in parallel and process various parts in different processes, which might make things faster again.

PierreBdR
Just what I was going to say, didn't type fast enough.
BenV
can u suggest how to make them run parallel.is there any thing to be added to the code?
kaki
Um, when you wrote "resort to caching", did you mean "resort to paging/swapping"?
Forest
parallel involves using threading - it's tricky business but you get the speedup based on the fact that executing your program is working on memory. It might take a few milliseconds to perform several operations. Reading files from the hard disk is exponentially slower, so threading allows several "copies" of the program (not really, but sort of) to be accessing various chunks of data at once, so the CPU is wasting less time waiting to read from the file.
Wayne Werner
@Forest: indeed, sorry for the mistake
PierreBdR
A: 

30sec time difference? Define large. Everything that fits into an average's computer RAM would probably not take much more time than 30sec in total.

nils
A: 

Why do you think you need to read the file(s) into a list?

If you can open several small files and process each independently, then surely that means:

(a) that you don't need to read into a list, you can process any file (including 1 large file) a line at a time (avoiding running-out-of-real-memory problems)
or
(b) what you need to do is more complicated than you have told us.

John Machin