Forum Home
Press F1
Thread ID: 71604	2006-08-10 09:09:00	Is there such a thing as an internal flash drive?	charlesg (10959)	Press F1

Post ID	Timestamp	Content	User
477617	2006-08-10 23:52:00	You could spend quite a lot of money for no real improvement in speed. OS's should vknow about I/O. That's what they are for. Buffering means that, almost always, when the CPU wants data, it's already in memory. When the CPU writes, it wriites to a buffer, and carries on. In a single user system, there's very little time sopend waiting on disk I/O. Of course in an application like this you won't be using the CPU and memory to also watch movies, listen to music, and download US TV shows so you won't be bored waiting. :D Ram disks were useful in the days of 5 Mbps disk interfaces. Theye were even better with floppies. :D These days, they just amount to a second layer of buffering (using a FS and directoiry system to make it a slow buffer).	Graham L (2)
477618	2006-08-11 08:01:00	Ram disks were useful in the days of 5 Mbps disk interfaces. Theye were even better with floppies. :D These days, they just amount to a second layer of buffering (using a FS and directoiry system to make it a slow buffer). What if you use it as a small extra drive/volume? (e.g. 3Gb would do if I had 4Gb of RAM in my PC...assuming that's possible....)	charlesg (10959)
477619	2006-08-12 02:05:00	Ram disks are OK, if you have (a) totally, absolutely reliable power, (b) totally, absolutely reliable (preferably ECC) memory, and (c) you are so totally, absolutely, methodical that you remember to save the contents to a real disk before you turn the computer off . Every time . Core memory would be better, but that was never (and never could be) as fast or anywhere as cheap as semiconductor . Otherwise, you might as well use the NUL: device . It's not worth the risk . Buy another fast disk . Or two . :cool: What is the speed problem, anyway? Surely you compile only one module at a time, then link with the unchanged stuff? You could probably get some improvement if you kept the complete app source, obj files, dlls, debugging files, etc, etc . . . on different disks (not partitions :) ) . One disk for OS and the compiler and other tools; one for the source and debugging files; one for the binaries and the etceteras would probably give as much improvement as you could hope for . That would reduce the amount of seeking that the heads do, and that's the slowest part of disk activity) .	Graham L (2)
477620	2006-08-12 21:13:00	Ram disks are OK, if you have (a) totally, absolutely reliable power, (b) totally, absolutely reliable (preferably ECC) memory, and (c) you are so totally, absolutely, methodical that you remember to save the contents to a real disk before you turn the computer off. Every time. Looks like it will do it for you. www.cenatek.com But I agee they're not 100% foolproof.	charlesg (10959)
477621	2006-08-12 22:00:00	What is the speed problem, anyway? Surely you compile only one module at a time, then link with the unchanged stuff? Yes, that's the theory. But this is a project that's been continuously developing about 10 years, containing around 1300 source files, so weeding out all the unnecessary dependencies (which I have tried to do) is non-trivial - plus people keep wanting me to add new features rather than improve the existing architecture :( Also, MSDEV decides to save the project settings every few minutes, often for no obvious reason, and even that takes a couple of minutes because it's so huge. Which means that the whole thing seizes up at irregular intervals. Not good for the concentration. If even THAT file was on a RAM disc it would help somewhat, methinks.	charlesg (10959)
477622	2006-08-13 01:14:00	... One disk for OS and the compiler and other tools; one for the source and debugging files; one for the binaries and the etceteras would probably give as much improvement as you could hope for. (That would reduce the amount of seeking that the heads do, and that's the slowest part of disk activity). might be your best hope.	Graham L (2)
1 2