JJLUCSY@MTUS5.BITNET (02/12/91)
Could someone please tell me what is the fastest way to dump a chunk of memory to disk using either Turbo C v.2 or Turbo C++. I'm not to particular on the method, but it should be real quick. Thanks in advance. Joel Lucsy (JJLUCSY@MTUS5.BITNET or JJLUCSY@MTUS5.CTS.MTU.EDU)
mcastle@mcs213f.cs.umr.edu (Mike Castle {Nexus}) (02/17/91)
In article <91043.105618JJLUCSY@MTUS5.BITNET> JJLUCSY@MTUS5.BITNET writes: >Could someone please tell me what is the fastest way to dump a chunk of memory >to disk using either Turbo C v.2 or Turbo C++. I'm not to particular on the >method, but it should be real quick. Thanks in advance. > >Joel Lucsy (JJLUCSY@MTUS5.BITNET or JJLUCSY@MTUS5.CTS.MTU.EDU) Try fwrite. The prototype is: size_t fwrite(const void *ptr, size_t size, size_t n, FILE *stream); It starts at *ptr and writes n records of size size to file pointed to by steam. -- Mike Castle (Nexus) S087891@UMRVMA.UMR.EDU (preferred) | RN ate my mcastle@mcs213k.cs.umr.edu (unix mail-YEACH!)| .newsrc! Life is like a clock: You can work constantly, and be right | I am not all the time, or not work at all, and be right twice a day. | happy :-<
pwb@newt.phys.unsw.OZ.AU (Paul W. Brooks) (02/18/91)
In article <2184@umriscc.isc.umr.edu>, mcastle@mcs213f.cs.umr.edu (Mike Castle {Nexus}) writes: > In article <91043.105618JJLUCSY@MTUS5.BITNET> JJLUCSY@MTUS5.BITNET writes: > >Could someone please tell me what is the fastest way to dump a chunk of memory > >to disk using either Turbo C v.2 or Turbo C++. I'm not to particular on the > >method, but it should be real quick. Thanks in advance. > > > > Try fwrite. The prototype is: > > size_t fwrite(const void *ptr, size_t size, size_t n, FILE *stream); > > It starts at *ptr and writes n records of size size to file pointed to by > steam. Sorry - incorrect. The fastest way is using low-level file access - write(). Using fwrite() requires the disk library internals to keep up to date with internal buffers, etc., and is quite slow. In my systems I usually get at least 3 times the speed when using write() instaed of fwrite()! There are a couple of things to watch, though. Preferably the file handle is obtained through the low-level call to open() or creat(). If you need to write to a file opened using the stream method (fopen()), and get to the underlying file handle using fileno(stream), then beware that the buffers probably will not be correct, and any later streams-based calls (fwrite(), fread(), fgetc(), etc etc) may fail unpredictably. There are techniques to bring the low-level and higher-level routines back in line, e-mail me if you need some hints. In my software I have to manipulate 500K astronomical images, and use only the low-level file operations: ( in MSC, with some rigorous bits omitted 8-) ) int file,row,bytesout; ( bits missed here ) file = creat("filename",S_IREAD|S_IWRITE); if (file==-1) bomb_out(); bytesout =write(file,bufptr,buflen); if (bytesout!=buflen) bomb_out(); ( more writes here! ) close(file); Anyone know of any faster way of accessing large amounts of disk data? I'd really appreciate hearing it. :-) Regards, Paul Brooks |Internet: pwb@newt.phys.unsw.edu.au Uni. of N.S.W. |If you have trouble sleeping, try lying on the end of Kensington NSW 2033| your bed. With a little luck you'll drop off. AUSTRALIA | - Mark Twain.
jdb@reef.cis.ufl.edu (Brian K. W. Hook) (02/18/91)
In article <1091@usage.csd.unsw.oz.au> pwb@newt.phys.unsw.OZ.AU (Paul W. Brooks) writes: |>In article <2184@umriscc.isc.umr.edu>, mcastle@mcs213f.cs.umr.edu (Mike Castle {Nexus}) writes: |>> In article <91043.105618JJLUCSY@MTUS5.BITNET> JJLUCSY@MTUS5.BITNET writes: |>> >Could someone please tell me what is the fastest way to dump a chunk of memory |>> >to disk using either Turbo C v.2 or Turbo C++. I'm not to particular on the |>> >method, but it should be real quick. Thanks in advance. |>> > |>> |>> Try fwrite. The prototype is: |>> |>> size_t fwrite(const void *ptr, size_t size, size_t n, FILE *stream); |>> |>> It starts at *ptr and writes n records of size size to file pointed to by |>> steam. |> |>Sorry - incorrect. The fastest way is using low-level file access - |>write(). Using fwrite() requires the disk library internals to keep up |>to date with internal buffers, etc., and is quite slow. In my systems I |>usually get at least 3 times the speed when using write() instaed of |>fwrite()! |> There are a couple of things to watch, though. Preferably the |>file handle is obtained through the low-level call to open() or creat(). If you |>need to write to a file opened using the stream method (fopen()), and |>get to the underlying file handle using fileno(stream), then beware that |>the buffers probably will not be correct, and any later streams-based |>calls (fwrite(), fread(), fgetc(), etc etc) may fail unpredictably. |>There are techniques to bring the low-level and higher-level routines |>back in line, e-mail me if you need some hints. In my software I have to |>manipulate 500K astronomical images, and use only the low-level file |>operations: |> |>Anyone know of any faster way of accessing large amounts of disk data? |>I'd really appreciate hearing it. :-) |>Regards, I have heard somewhere that open(), write(), close(), and read() were not defined in the ANSI standard because of their reliance on handles ( a DOS and UNIX system specific thing). Thus fopen() and the other stream based functions would seem to be a bit more portable. However, speed seems to be the issue here, so I would also look in the TC++ manual under _open() and the other file functions with a leading underscore. I don't know if they are any faster, but they seem to a bit more low level. Inline asm might be also used...:) Brian
trier@cwlim.INS.CWRU.Edu (Stephen C. Trier) (02/18/91)
Since you are using Turbo C, use _open, _write, and _close. _write is a direct call to MS-DOS's "write" function call. That's about as fast as you can get. If you _must_ use open, write, and close, be sure to do so in binary mode. It can be substantially faster than text mode, since it eliminates a lot of buffer-scanning. _open, _write, and _close automatically use binary mode. (It's inherent in their function.) -- Stephen Trier Case Western Reserve University Work: trier@cwlim.ins.cwru.edu Information Network Services Home: sct@seldon.clv.oh.us %% Any opinions above are my own. %%