The MASM Forum

General => The Laboratory => Topic started by: jj2007 on May 15, 2015, 10:53:10 AM

Title: FILE_ATTRIBUTE_TEMPORARY or FILE_FLAG_DELETE_ON_CLOSE
Post by: jj2007 on May 15, 2015, 10:53:10 AM
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...
Title: Re: FILE_ATTRIBUTE_TEMPORARY or FILE_FLAG_DELETE_ON_CLOSE
Post by: rrr314159 on May 15, 2015, 12:03:38 PM
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
Title: Re: FILE_ATTRIBUTE_TEMPORARY or FILE_FLAG_DELETE_ON_CLOSE
Post by: dedndave on May 15, 2015, 12:26:31 PM
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
Title: Re: FILE_ATTRIBUTE_TEMPORARY or FILE_FLAG_DELETE_ON_CLOSE
Post by: 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 (http://blogs.msdn.com/b/oldnewthing/archive/2003/10/07/55194.aspx)
Title: Re: FILE_ATTRIBUTE_TEMPORARY or FILE_FLAG_DELETE_ON_CLOSE
Post by: jj2007 on May 16, 2015, 04:23:02 AM
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 (http://blogs.msdn.com/b/oldnewthing/archive/2003/10/07/55194.aspx)

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 :(
Title: Re: FILE_ATTRIBUTE_TEMPORARY or FILE_FLAG_DELETE_ON_CLOSE
Post by: dedndave on May 16, 2015, 04:31:56 AM
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
Title: Re: FILE_ATTRIBUTE_TEMPORARY or FILE_FLAG_DELETE_ON_CLOSE
Post by: fearless on May 16, 2015, 05:39:52 AM
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.
Title: Re: FILE_ATTRIBUTE_TEMPORARY or FILE_FLAG_DELETE_ON_CLOSE
Post by: jj2007 on May 16, 2015, 07:13:50 AM
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: