FILE_ATTRIBUTE_TEMPORARY or FILE_FLAG_DELETE_ON_CLOSE

[jj2007]

In a somewhat exotic application, I need to write many small strings to a temporary file, just to re-read them immediately by a function that can read only from files, not from buffers.

So I thought a file that is only in memory might be faster. The only way to achieve this in Windows seems to use FILE_ATTRIBUTE_TEMPORARY or FILE_FLAG_DELETE_ON_CLOSE

Unfortunately, it seems to have the opposite effect :(

Some timings:

Code Select Expand

Intel(R) Core(TM) i5-2450M CPU @ 2.50GHz
131 ms for 350 files, bytes=1841182     normal temp file
473 ms for 350 files, bytes=1841182     memory temp file

198 ms for 350 files, bytes=1841182     normal temp file
443 ms for 350 files, bytes=1841182     memory temp file

155 ms for 350 files, bytes=1841182     normal temp file
463 ms for 350 files, bytes=1841182     memory temp file

Intel(R) Celeron M
55 ms for 375 files, bytes=2059538
52 ms for 375 files, bytes=2059538

51 ms for 375 files, bytes=2059538
56 ms for 375 files, bytes=2059538

54 ms for 375 files, bytes=2059538
70 ms for 375 files, bytes=2059538

Interesting also that the old Celeron on XP is a lot faster than the i5 on Win7-64...

[rrr314159]

I've run into something similar, it's amazing how fast disk access can be, rarely worth the trouble to avoid it in a case like this (where it's just a one-shot conversion or whatever, not happening constantly). Still no doubt a mem-based file could be faster. Possibly (give the devil his due) MS didn't bother to optimize this sort of thing because disk files are, in fact, so fast

[dedndave]

when you write to and read from a file, it goes into a memory buffer
depending on the size, the entire contents are probably still in the buffer
the buffers are probably considerably larger than DOS days   :P

[Zen]

JOCHEN,
This probably isn't what you're looking for,...but, it might give you a useful idea,...
Stupid Memory-Mapping Tricks, Raymond Chen

[jj2007]

JOCHEN,
This probably isn't what you're looking for,...but, it might give you a useful idea,...
Stupid Memory-Mapping Tricks, Raymond Chen

Thanks, Chen is interesting as usual, he knows many tricks, but this is indeed not what I need...

My problem is that I can easily get the contents of a bitmap file, e.g. GIF, by unzipping it to a buffer. But all functions that yield bitmap handles ask either for resources or for real files. So I have to unzip to a file and reload it. Speedwise it's not a problem, I just wanted to avoid accessing the hard disk. Bad luck :(

[dedndave]

there's probably a way to do that using IStream - or some other form of streaming I/O
what you might do, is examine the code used to load a resource
i think i wrote one last year called LoadRsrc, or something like that

[fearless]

If its a bitmap unzipped in memory, just use CreateDIBitmap to create the bitmap, point it in the right direction of all data in memory and it returns a hBitmap that you can use with other functions.

[jj2007]

Actually, the bitmaps are present as gif files, so the CreateDIBitmap solution won't work. IStream... maybe, but again, no idea how that works with gif.

GdipCreateBitmapFromFile does a pretty good job, though, and if it stays in the 10 ms range per file, printing to file and re-reading is easy enough. Thanks anyway for your good advice :icon14: