Blistering SolidWorks speed....

An interesting idea. I can imagine copying a project into the RAMdisk in the morning with super-quick loading and (and re-loading after a crash). On my machine, it takes a full 15 minutes to load a typical drawing, make a simple change, update drawing views, print, save and shut down. I imagine this could cut that time drawstically.

I'd love to see the SPEC benchmark run on this rig. Just how low can the I/O numbers go?

D. Short wrote: Why not run Ship in a Bottle and let us know what you got?

Another question.... SW04 is almost 1GB on my C: drive. How long does it take to copy this all into the RAMdisk at bootup?

if interested in reducing, you can save about 400~450mb by omitting realview

It is probably 1gb because of all the add-ins, i.e. Toolbox and the textures for Realview. The install we did was with no add-ins.

Overall, we have 2 apps on the ramdrive (512mb), SolidWorks takes about

350-400mb (I am not in the office right now).

The startup speed doesn't seem to be much slower as the machine is a

3.2Ghz and the disks are fast SATA 10,000rpm drives.

Even if it takes 5 minutes longer (which it would not) to boot winxp, the speed increase in running all day long would more than be able to justify the long start-up time. The only time we shut down or reboot our machines is after applying new drivers or patching the OS.

Believe me, this is well worth a try, I wouldn't believe you would be disappointed at all.

D

It is interesting you mentioned running a program in RamDisk. I used to do that in slower Macs with the OS a long time back. There are programs that load themselves into RAM and run super-fast that way and the one I've used most recently is the Panorama database program from ProVue Development in Huntington Beach, CA. It is cross-platform, and indeed fast.

I have never thought about it until you mentioned it, but I now wonder why SolidWorks couldn't be designed like Panorama. It sounds like we have the RAM capacity to do it, even on laptops today.

Obviously, there are safety and programming issues and not all users might want to run an application in RAM on an older machine which can't take a large amount of RAM.

Fascinating - Bo

Isn't there something missing in this conversation???? Or is it just me???? How is this going to help when your model pushes 1.6Gb as it is and doesn't behave properly because SW says it can't obtain the required memory to complete the task? Any RAM taken away to load unnecessary code, rather than the model, is, in this instance, not wise use of resources.

Now, before all of you flame me (fire suit on,) of course I agree that not everyone is doing stuff that large and trying to use all of 2Gb of installed RAM. So, yes, I agree, if you have the room to suck up RAM with a RAM disk, it would probably work pretty nicely.

A good example of that is BIOS shadowing, which most people already are doing, they just don't know it. Ok, fire suit off. :-)

WT

Firstly, I didn't add the bit saying that you *should* consider the amount of ram that you need to do your work before you take some away... my bad, but I'm pretty confident that everyonme here would be able to do the math ;-)

Laptops could be a problem as they can not take as much ram as a workstation. My Dell Inspiron 8200 will only take 1Gb, so I would be hesitant to take 512mb away from that, albeit I have been working comfortably on 512 for quite some time on medium sized assemblies (150-300 component drawings).

Modern workstations are another story, although. Put 3 or 4Gb of ram in and give some to a ramdisk... ram is cheap these days, time is expensive.

Wayne Tiffany wrote:

I'm confused here... I was given the impression a long time ago that Solidworks does load a primary amount of code into ram. Consider when you load Solidworks off a network... it doesn't run off the network hard drive, it loads off the network hard drive into something... like local ram. It seem that Solidworks would launch instantly from a ram drive but it shouldn't "run" any faster. AFAIK, Solidworks loads anything that it happens to be using into ram first. Most programs these days do not "run" off the hard drive. The paging that Windows does and the time it takes to load from hard drive to ram is what we're noticing as being slow.

- Eddy

I've read a little more about this thing now.... Apparently, you can start using the data before it's all loaded into RAM. So, if you start SW immediately after a reboot, it might start as if it were coming off of only the HD. Is that right?

It's a shame that folder couldn't be linked to some other mount point to keep it out of the RAMdisk.

Not installing RealView next time is definitely a possibility. I suspect it was added just to one-up Inventor's textured material display. I installed it this time just because it IS sorta fun to play with. No professional use to me though.

I'm thinking a half gig for SW and another for current projects would be a nice setup. Nothing but rebuild time. It would actually save me the cost and risk of a RAID-0 array. Then again, the software + 1 GB is probably twice the cost of a second drive.

It's a very interesting idea. I wonder how this will mix in with Windows for AMD64. The huge memory space should make it possible to install obscene amounts of RAM for this sort of thing...

"Eddy Hicks" wrote in news: snipped-for-privacy@dls.net:

I think that's the whole point. Startup, load, and save would all be done from RAM instead of the hard disk. This should have no effect at all on operations that are CPU or graphics intensive. That is, unless Windows has to page to the HD, in which case you don't have enough RAM for this stunt anyway.

For all the time spent saving in anticipation of a crash, I'd think that this thing could really pay for itself.

This stuff isn't rocket science. Ram drives have been around forever. The new ram drive softwares, like superspeed just add twists to the old technology. Basically it works in one of two ways...

Write-through in which your data is safe because it gets copied to hard drive; which means your basically back to the speed of your hard drive, except now you have less ram to the OS and the Apps that need it.

and

Write-back (or lazy write) in which your data gets written to the hard drive every once in a while and also which means your data is less than "real time" safe and again, you have less ram to the OS and Apps.

Either situation tells me, with respect to SW, your better off leaving the ram to the OS. Definitely not for me, but to any of you who use it, good luck.

- Eddy

Yes, the technology has been around for quite a while (even DOS days), but superspeed is quite a bit different and takes it to a new level.

The ramdrive shows as an actual hard drive that you can format as you wish (fat, raw, or ntfs) and then you copy or install the application(s) on that drive. When you shut down or reboot, the data is automatically backed up to a magnetic drive for use with the next session.

I see this much different than your write through/back methods explained below. The *WHOLE* application is on the ramdrive, so the hard drives never need to be touched.

Again, ram is so cheap today, why not buy an extra 1 or 2Gb for the real increase in speed, I would think that the small amount of expenditure would by far pay for itself in a short time.

I posted this because I have never seen it discussed here but see much discussion on poor performance. We are seeing very significant benefits.

D.

Eddy Hicks wrote:

so what happens if the power goes off?

And when exactly _DOES_ it save to a hard drive (local or network)?

Or what happens when SW crashes? Which I know it will. What happens to the previous 6 hours of work that I've done?

pardon me if I seen a bit confused/concerned about the whole thing.

--nick e.

Speaking of alternate "drives"....and Completely Offtopic(tm)..has anyone seen this method of "installing"?

basically "run" the program off the internet. Or, alternatively, off a central location on your Lan I suppose. Interesting to say the least. I suppose it would make keeping all your clients up to date with the same version a snap.

"Eddy Hicks" wrote in news: snipped-for-privacy@dls.net:

While the data is being moved to the HD, it's as secure as the RAMdisk device driver and the general stability of the system allow. I agree there is some risk in adding the extra device river to the process. That risk seems very acceptable if my typical save can be reduced from minutes to seconds. I'd probably save more often, and might even enable saving of auto-recover data again. This might actually increase my data security by allowing me to save more often. I love the idea that I might not have to wait for the HD anymore. D, is this how it works in practice?

To me, this isn't an issue, because I've always used a battery backup on my workstations. If I have enough battery time to copy the RAMdisk to a physical disk, then everything is ok. That reminds me, I need to check into my UPS. Last time the power went out, it just gave up. I think I accidentally plugged the second monitor into it.

If SW crashes, the data is as secure as if it were saved to a physical disk, minus the stability of the RAMdisk driver and the system in general. So crashing SW shoudln't be any more of a nuisance than it already is. Maybe less, because you could save more often, since it takes so much less time.

but isn't it saved to the ramdisk? or am I missing something?

-nick e.