News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

FILE_ATTRIBUTE_TEMPORARY or FILE_FLAG_DELETE_ON_CLOSE

Started by jj2007, May 15, 2015, 10:53:10 AM

Previous topic - Next topic

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:
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
I am NaN ;)

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

Quote from: Zen on May 16, 2015, 03:48:25 AM
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: