the 3GB Switch?
in [SolidWorks]
|
From: "Gil Alsberg" gil@"remove on 19 Oct 2006 11:08 Thanks Mike, I did it, and it works until now fine! Cheers, Gil "Michael Eckstein" <mike.ecksteinONOSPAMHERE(a)ONOSPAMHEREcharter.net> wrote in message news:D1MZg.291$nL3.166(a)newsfe04.lga... >I have been using the 3 GB switch for over 2 years now and have not had any >issues. > Here is a copy of my boot.init file file. Notice the last 2 lines are > identical except for the "3gb". At start up you will be given the option > of 2 different operating parameters, one with 3gb, one without. The > options will read the same at boot, but put the 3gb line before the one > without 3gb in the init file and it will be the default startup. If you > ever need to go back to the original setup highlight the lower line at > boot and hit "enter" . > > [boot loader] > timeout=5 > default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS > [operating systems] > multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP > Professional" /fastdetect /3gb > multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP > Professional" /fastdetect > > Good Luck > Mike > > > > "Gil Alsberg" <gil@"remove me"zoopee.org> wrote in message > news:newscache$kntd7j$zgg$1(a)news.actcom.co.il... >>I know this was discussed already many times in this NG, but I can't find >>those posts..... How do I set SolidWorks to be able to use 3GB of memory? >> >> Thanks, >> Gil >> > >
From: "Gil Alsberg" gil@"remove on 19 Oct 2006 14:10 > I don't know for sure how the page file allocation is handled, and it may > be that once it is expanded, it stays allocated until that program closes. > I wouldn't worry about that too much as it's space on your hard drive, and > as long as you see it go down when you close SW, it's probably working > properly. Wayne, I decided to investigate in this matter of exaggerated page file size while doing the animation rendering, and showed it to my brother who is a programmer and deals a lot with OS management and programming: He told me that what The task manager shows is completely not normal for an application like solidworks combined with animator and photoworks. he says that the fact that the page file increases endlessly further and further as solidworks continues with the rendering job indicates of something which is called a "Memory Leak", which to his opinion is definitely a bug and should not happen. so I guess the only option is to hope SW will release another SP and fix this with it or at least have fixed it for SW2007. Anyway, in this particular case setting the 3GB switch will not help as much. it just postpones the critical second where SW announces that it ran out of memory, to a later stage of the animation rendering job. Cheers, Gil
From: efhicks on 22 Oct 2006 00:49 I'm glad you posted that because it will lend some credibility to my observation that Solidworks has had a memory leak issue for years. I don't know how it's possible, nor why it can't be fixed but I've been working in Solidworks since version '98 and you can predict with staggering accuracy when it it will crash to desktop and under what conditions. The versions from 2003 on were the worst, with (for me anyway) 2006 being the medal holder for all time worst, with '05 close behind. Until 2001 I was in charge of Solidworks for a large group of design engineers, including myself, and then in 2001 I incorporated my own design firm and chose Solidworks. I've seen it run on countless machines under very controlled conditions, especially in my own company and its amazing. Memory leak is not a term that should exist for established software yet it's still there. I've switched to '07(sp1) a couple weeks ago because '06 was the worst I've ever seen. In our small office you could hear the Windows XP crash sound about 2-3 times per day reliably. I swear it's better in '07 but we've stilled crashed it. For us, Solidworks "major" issues boil down to this... 1) pesky memory problems (or poor use). If it's not a memory leak then it's just plain bad memory management. I suspect they don't properly release memory when closing files. In other words, the more parts and assemblies you open the more memory that gets taken up, obviously, but closing files doesn't reliably reduce the saturation. Is that a leak technically, maybe not but the result is the same. Boom, say hello to my little desktop. 2) network issues. It's no surprise that SW works better with all files local but for any collaborated workgroup that is not a good option. It's an option but not a good one. Even with dead-nuts reliable high speed low latency gigabit networking SW still has a problem with network operation. After this many years of being an "expert" I still can't put my finger on what or why but we've all fealt it. I've had a top notch app engineer in from our Var a couple times and our ship is tight. Analogously it's like data is flying through an intersection and gets broadsided by other data. Again, you can feel it coming. Hit or miss, but when SW has to wait too long for an expected piece of data it smacks a wall. And finally 3) Toolbox. What can I say that hasn't already been said. Toolbox is the best example of how to make the worst of points 1 & 2. Call me crazy but there have been numerous times using '07 where it would pause and for sure in any other version it would have bombed but I'll be damned if it didn't come back. It's so noticeable it's scary. Again, it has still crashed but maybe they've at least begun to address the issues. I'm not saying that the developers don't do anything between releases but certainly in the past stability and performance have taken a backseat to toolbar buttons and new "features". Sorry for the diatribe but you're not crazy... memory usage (or misusage) was and I believe might still be number one on the list. - Eddy www.sldinc.com "Gil Alsberg" <gil@"remove me"zoopee.org> wrote in message news:newscache$1hae7j$pvg$1(a)news.actcom.co.il... >> I don't know for sure how the page file allocation is handled, and it may >> be that once it is expanded, it stays allocated until that program >> closes. I wouldn't worry about that too much as it's space on your hard >> drive, and as long as you see it go down when you close SW, it's probably >> working properly. > > Wayne, > I decided to investigate in this matter of exaggerated page file size > while doing the animation rendering, and showed it to my brother who is a > programmer and deals a lot with OS management and programming: > > He told me that what The task manager shows is completely not normal for > an application like solidworks combined with animator and photoworks. he > says that the fact that the page file increases endlessly further and > further as solidworks continues with the rendering job indicates of > something which is called a "Memory Leak", which to his opinion is > definitely a bug and should not happen. so I guess the only option is to > hope SW will release another SP and fix this with it or at least have > fixed it for SW2007. > > Anyway, in this particular case setting the 3GB switch will not help as > much. it just postpones the critical second where SW announces that it ran > out of memory, to a later stage of the animation rendering job. > > Cheers, > Gil >
From: ken on 22 Oct 2006 13:45 Keep in mind that when you open an application, not all portions of it are loaded into memory. As you use it, certain libraries of code are constantly being added to memory as you use the functions that need them. This is why an applications footprint grows as you open and subsequently close different types of files and use different functions within the app. Not saying that there isn't a leak, but possibly another reason. Ken "efhicks" <efhicks(at)hicksgroup.com> wrote in message news:AP2dnb7FBN3fZafYnZ2dnUVZ_rGdnZ2d(a)comcast.com... > I'm glad you posted that because it will lend some credibility to my > observation that Solidworks has had a memory leak issue for years. I > don't know how it's possible, nor why it can't be fixed but I've been > working in Solidworks since version '98 and you can predict with > staggering accuracy when it it will crash to desktop and under what > conditions. The versions from 2003 on were the worst, with (for me > anyway) 2006 being the medal holder for all time worst, with '05 close > behind. > > Until 2001 I was in charge of Solidworks for a large group of design > engineers, including myself, and then in 2001 I incorporated my own design > firm and chose Solidworks. I've seen it run on countless machines under > very controlled conditions, especially in my own company and its amazing. > Memory leak is not a term that should exist for established software yet > it's still there. I've switched to '07(sp1) a couple weeks ago because > '06 was the worst I've ever seen. In our small office you could hear the > Windows XP crash sound about 2-3 times per day reliably. I swear it's > better in '07 but we've stilled crashed it. For us, Solidworks "major" > issues boil down to this... 1) pesky memory problems (or poor use). If > it's not a memory leak then it's just plain bad memory management. I > suspect they don't properly release memory when closing files. In other > words, the more parts and assemblies you open the more memory that gets > taken up, obviously, but closing files doesn't reliably reduce the > saturation. Is that a leak technically, maybe not but the result is the > same. Boom, say hello to my little desktop. 2) network issues. It's no > surprise that SW works better with all files local but for any > collaborated workgroup that is not a good option. It's an option but not > a good one. Even with dead-nuts reliable high speed low latency gigabit > networking SW still has a problem with network operation. After this many > years of being an "expert" I still can't put my finger on what or why but > we've all fealt it. I've had a top notch app engineer in from our Var a > couple times and our ship is tight. Analogously it's like data is flying > through an intersection and gets broadsided by other data. Again, you can > feel it coming. Hit or miss, but when SW has to wait too long for an > expected piece of data it smacks a wall. And finally 3) Toolbox. What can > I say that hasn't already been said. Toolbox is the best example of how > to make the worst of points 1 & 2. > > Call me crazy but there have been numerous times using '07 where it would > pause and for sure in any other version it would have bombed but I'll be > damned if it didn't come back. It's so noticeable it's scary. Again, it > has still crashed but maybe they've at least begun to address the issues. > I'm not saying that the developers don't do anything between releases but > certainly in the past stability and performance have taken a backseat to > toolbar buttons and new "features". > > Sorry for the diatribe but you're not crazy... memory usage (or misusage) > was and I believe might still be number one on the list. > > - Eddy > www.sldinc.com > > > "Gil Alsberg" <gil@"remove me"zoopee.org> wrote in message > news:newscache$1hae7j$pvg$1(a)news.actcom.co.il... >>> I don't know for sure how the page file allocation is handled, and it >>> may be that once it is expanded, it stays allocated until that program >>> closes. I wouldn't worry about that too much as it's space on your hard >>> drive, and as long as you see it go down when you close SW, it's >>> probably working properly. >> >> Wayne, >> I decided to investigate in this matter of exaggerated page file size >> while doing the animation rendering, and showed it to my brother who is a >> programmer and deals a lot with OS management and programming: >> >> He told me that what The task manager shows is completely not normal for >> an application like solidworks combined with animator and photoworks. he >> says that the fact that the page file increases endlessly further and >> further as solidworks continues with the rendering job indicates of >> something which is called a "Memory Leak", which to his opinion is >> definitely a bug and should not happen. so I guess the only option is to >> hope SW will release another SP and fix this with it or at least have >> fixed it for SW2007. >> >> Anyway, in this particular case setting the 3GB switch will not help as >> much. it just postpones the critical second where SW announces that it >> ran out of memory, to a later stage of the animation rendering job. >> >> Cheers, >> Gil >> > >
From: efhicks on 22 Oct 2006 14:55
No doubt Ken, that's the part you expect. The part you don't expect is the growing and growing and growing until you've hit the invisible ceiling. I've never had another application do this and we're talking other modelers as well. SDRC running on NT using their tweaked version of Hummingbird, Pro/e on NT, Unigraphics on Sun/HP, etc. They share a similar core/architectural model yet none hit the ceiling like Solidworks. You had files you couldn't load on some machines but that's a different way of handling the memory usage problem. In those case you go back, dumb down the files and try again. I theorize it's being forced at the architecture level, meaning it's a problem with the foundation and that's why it isn't fixed yet after all these years. As systems have grown and memory more available it is probably looked at as a liveable situation for them. After all, we've all dealt with it right? Not sure what they could do about it now, if anything. After this much time, rewrites at the core level are not typically justified. Again, '07 seems magically better at this, albeit not perfect. So now we CTD occasionally but it's a little harder to predict when. :) - Eddy "ken" <goaway(a)noway.gov> wrote in message news:ehgan8$47s$1(a)news.netins.net... > Keep in mind that when you open an application, not all portions of it are > loaded into memory. As you use it, certain libraries of code are > constantly being added to memory as you use the functions that need them. > This is why an applications footprint grows as you open and subsequently > close different types of files and use different functions within the app. > Not saying that there isn't a leak, but possibly another reason. > > Ken > "efhicks" <efhicks(at)hicksgroup.com> wrote in message > news:AP2dnb7FBN3fZafYnZ2dnUVZ_rGdnZ2d(a)comcast.com... >> I'm glad you posted that because it will lend some credibility to my >> observation that Solidworks has had a memory leak issue for years. I >> don't know how it's possible, nor why it can't be fixed but I've been >> working in Solidworks since version '98 and you can predict with >> staggering accuracy when it it will crash to desktop and under what >> conditions. The versions from 2003 on were the worst, with (for me >> anyway) 2006 being the medal holder for all time worst, with '05 close >> behind. >> >> Until 2001 I was in charge of Solidworks for a large group of design >> engineers, including myself, and then in 2001 I incorporated my own >> design firm and chose Solidworks. I've seen it run on countless machines >> under very controlled conditions, especially in my own company and its >> amazing. Memory leak is not a term that should exist for established >> software yet it's still there. I've switched to '07(sp1) a couple weeks >> ago because '06 was the worst I've ever seen. In our small office you >> could hear the Windows XP crash sound about 2-3 times per day reliably. >> I swear it's better in '07 but we've stilled crashed it. For us, >> Solidworks "major" issues boil down to this... 1) pesky memory problems >> (or poor use). If it's not a memory leak then it's just plain bad memory >> management. I suspect they don't properly release memory when closing >> files. In other words, the more parts and assemblies you open the more >> memory that gets taken up, obviously, but closing files doesn't reliably >> reduce the saturation. Is that a leak technically, maybe not but the >> result is the same. Boom, say hello to my little desktop. 2) network >> issues. It's no surprise that SW works better with all files local but >> for any collaborated workgroup that is not a good option. It's an option >> but not a good one. Even with dead-nuts reliable high speed low latency >> gigabit networking SW still has a problem with network operation. After >> this many years of being an "expert" I still can't put my finger on what >> or why but we've all fealt it. I've had a top notch app engineer in from >> our Var a couple times and our ship is tight. Analogously it's like data >> is flying through an intersection and gets broadsided by other data. >> Again, you can feel it coming. Hit or miss, but when SW has to wait too >> long for an expected piece of data it smacks a wall. And finally 3) >> Toolbox. What can I say that hasn't already been said. Toolbox is the >> best example of how to make the worst of points 1 & 2. >> >> Call me crazy but there have been numerous times using '07 where it would >> pause and for sure in any other version it would have bombed but I'll be >> damned if it didn't come back. It's so noticeable it's scary. Again, it >> has still crashed but maybe they've at least begun to address the issues. >> I'm not saying that the developers don't do anything between releases but >> certainly in the past stability and performance have taken a backseat to >> toolbar buttons and new "features". >> >> Sorry for the diatribe but you're not crazy... memory usage (or misusage) >> was and I believe might still be number one on the list. >> >> - Eddy >> www.sldinc.com >> >> >> "Gil Alsberg" <gil@"remove me"zoopee.org> wrote in message >> news:newscache$1hae7j$pvg$1(a)news.actcom.co.il... >>>> I don't know for sure how the page file allocation is handled, and it >>>> may be that once it is expanded, it stays allocated until that program >>>> closes. I wouldn't worry about that too much as it's space on your hard >>>> drive, and as long as you see it go down when you close SW, it's >>>> probably working properly. >>> >>> Wayne, >>> I decided to investigate in this matter of exaggerated page file size >>> while doing the animation rendering, and showed it to my brother who is >>> a programmer and deals a lot with OS management and programming: >>> >>> He told me that what The task manager shows is completely not normal for >>> an application like solidworks combined with animator and photoworks. he >>> says that the fact that the page file increases endlessly further and >>> further as solidworks continues with the rendering job indicates of >>> something which is called a "Memory Leak", which to his opinion is >>> definitely a bug and should not happen. so I guess the only option is to >>> hope SW will release another SP and fix this with it or at least have >>> fixed it |