Memory or Disk?
-
There seems to be a lot of articles written which promote the use of storing DHTML data from a C++ application in memory, rather than reading/writing temporary files to disk. However, there doesn't appear to be a lot of support backing this "best-practices" theory, other than disk caching seems slower or more sloppy (for lack of a better word) than memory caching, and that the temporary files will need to be deleted afterwards. I'm going to have to raise a brow on this one and get some others thinking about it before we all start writing a bunch of applications based on this memory usage theory. The idea is that by initially navigating to "about:blank" and insuring that the document is loaded, we can then write directly to the HTML document as it sets in memory. The alternative approach obviously, is to write to a temporary file that is stored on the hard disk, "C:\\temp\\temp.htm" for example. I've looked deeply into both of these methods and I have to say that I'm leaning a little towards the disk caching but maybe someone can raise a point that I haven't considered. Firstly, most of the articles claim that there'd be a need to write temporary "files" (plural), which is a little misleading. If you can write your entire DHTML document to one "about:blank", then you should be able to write the same content to one "temp.htm". In terms of clean-up, deleting a temporary file is no different than releasing values stored in memory and Microsoft has confirmed that there are issues with releasing BSTR's from memory, even in Internet Explorer, which is causing memory leaks in most of these memory-based solutions. Simply put, a rebel file will cause far less damage than an orphaned memory block. After all and in most cases, we have Gig's worth of free and available disk space to work with and only a few hundred Meg's worth of memory, not to mention the fact that that few hundred MB's is being shared with the operating system and all of the other applications that are running on the desktop and using memory. Additionally, the nature of a Microsoft OS is to buffer memory in an out of a paging file, so the data is eventually going to be written to the disk anyway, and into a space that is restricted by the amount of memory that is available to the system. True, the OS will "take care of it for you" but when you let something else take care of something for you, you give up the control you have over how it's handled. And does your file need to be temporary? Do you even need to delete the file? In so
-
There seems to be a lot of articles written which promote the use of storing DHTML data from a C++ application in memory, rather than reading/writing temporary files to disk. However, there doesn't appear to be a lot of support backing this "best-practices" theory, other than disk caching seems slower or more sloppy (for lack of a better word) than memory caching, and that the temporary files will need to be deleted afterwards. I'm going to have to raise a brow on this one and get some others thinking about it before we all start writing a bunch of applications based on this memory usage theory. The idea is that by initially navigating to "about:blank" and insuring that the document is loaded, we can then write directly to the HTML document as it sets in memory. The alternative approach obviously, is to write to a temporary file that is stored on the hard disk, "C:\\temp\\temp.htm" for example. I've looked deeply into both of these methods and I have to say that I'm leaning a little towards the disk caching but maybe someone can raise a point that I haven't considered. Firstly, most of the articles claim that there'd be a need to write temporary "files" (plural), which is a little misleading. If you can write your entire DHTML document to one "about:blank", then you should be able to write the same content to one "temp.htm". In terms of clean-up, deleting a temporary file is no different than releasing values stored in memory and Microsoft has confirmed that there are issues with releasing BSTR's from memory, even in Internet Explorer, which is causing memory leaks in most of these memory-based solutions. Simply put, a rebel file will cause far less damage than an orphaned memory block. After all and in most cases, we have Gig's worth of free and available disk space to work with and only a few hundred Meg's worth of memory, not to mention the fact that that few hundred MB's is being shared with the operating system and all of the other applications that are running on the desktop and using memory. Additionally, the nature of a Microsoft OS is to buffer memory in an out of a paging file, so the data is eventually going to be written to the disk anyway, and into a space that is restricted by the amount of memory that is available to the system. True, the OS will "take care of it for you" but when you let something else take care of something for you, you give up the control you have over how it's handled. And does your file need to be temporary? Do you even need to delete the file? In so
WolfSupernova wrote: Disk access speed has increased right along with all of the other processing speeds over the years and frankly, I'd rather my customers complain about my application being a little slower in response time (if it's even noticable) than spreading around words and phrases about my application like "resource hog" and "memory leaks", which can be a deal breaker. You know why they complain about having less memory on their machines? It's because, when you don't have enough memory available, the OS will use the disk. The current fastest disks are still at least 1,000 times slower than the current slowest memory chips. I don't really know what are the issues about storing DHTML files in memory, but, basically, what you are asking is: is it worthy have a slightly faster software, but leaky? OTOH, a browser builds an in-memory copy of everything that you ask it to read from the disk. Build a large test file and ask for IE to open it and you'll understand what I mean. So, storing a DHTML on disk for viewing won't save you memory, unless you have bugs. Trying to make bits uncopyable is like trying to make water not wet. -- Bruce Schneier By the way, dog_spawn isn't a nickname - it is my name with an underscore instead of a space. -- dog_spawn
-
There seems to be a lot of articles written which promote the use of storing DHTML data from a C++ application in memory, rather than reading/writing temporary files to disk. However, there doesn't appear to be a lot of support backing this "best-practices" theory, other than disk caching seems slower or more sloppy (for lack of a better word) than memory caching, and that the temporary files will need to be deleted afterwards. I'm going to have to raise a brow on this one and get some others thinking about it before we all start writing a bunch of applications based on this memory usage theory. The idea is that by initially navigating to "about:blank" and insuring that the document is loaded, we can then write directly to the HTML document as it sets in memory. The alternative approach obviously, is to write to a temporary file that is stored on the hard disk, "C:\\temp\\temp.htm" for example. I've looked deeply into both of these methods and I have to say that I'm leaning a little towards the disk caching but maybe someone can raise a point that I haven't considered. Firstly, most of the articles claim that there'd be a need to write temporary "files" (plural), which is a little misleading. If you can write your entire DHTML document to one "about:blank", then you should be able to write the same content to one "temp.htm". In terms of clean-up, deleting a temporary file is no different than releasing values stored in memory and Microsoft has confirmed that there are issues with releasing BSTR's from memory, even in Internet Explorer, which is causing memory leaks in most of these memory-based solutions. Simply put, a rebel file will cause far less damage than an orphaned memory block. After all and in most cases, we have Gig's worth of free and available disk space to work with and only a few hundred Meg's worth of memory, not to mention the fact that that few hundred MB's is being shared with the operating system and all of the other applications that are running on the desktop and using memory. Additionally, the nature of a Microsoft OS is to buffer memory in an out of a paging file, so the data is eventually going to be written to the disk anyway, and into a space that is restricted by the amount of memory that is available to the system. True, the OS will "take care of it for you" but when you let something else take care of something for you, you give up the control you have over how it's handled. And does your file need to be temporary? Do you even need to delete the file? In so
WolfSupernova wrote: After all and in most cases, we have Gig's worth of free and available disk space to work with and only a few hundred Meg's worth of memory You may, I don't. Just like a gas, my file storage fills to all available space. I keep having to delete stuff so I can put new stuff on. WolfSupernova wrote: And does your file need to be temporary? I sure hope so! I don't need tons of small files filling my temp directory! I hourly clean out my temp directory. The more files you have in a directory, the slower it is to locate them. Microsoft has a scheme whereby they break up the Temporary Internet Files in multiple directories and then have a file that it searches to find the actual file. WolfSupernova wrote: And finally, Microsoft itself uses temporary Internet files for caching information and they've developed both the Operating System and a pretty popular little web browser too, so maybe they know something we don't know? Sure, like how to cache web files between computer reboots. If you're just going to show a file thats generated on the fly, why cache it? In fact, IE won't cache certain files that a website flags as being generated on the fly. WolfSupernova wrote: Firstly, most of the articles claim that there'd be a need to write temporary "files" (plural), which is a little misleading. If you can write your entire DHTML document to one "about:blank", then you should be able to write the same content to one "temp.htm". So, you can write out all the images into the DHTML as well? That'd be a neat trick. And it'd bloat your html page too. So, my opinion is, the amount of memory needed for small files to be placed into an IE window is small and insignificant and is best suited for storing in memory. IE probably won't cache it anyways if it's on the file system. But don't get me wrong, it depends on what you're doing. Not all apps should keep everything in memory. I just feel that most of the apps write out a small amount of html anyways. I've found other solutions for displaying html, like QHTM, HtmlLayout, or PBears THtmlViewer. YMMV, but mine is sticking to memory. A hard drive is for persistent data. -- Joel Lucsy