Slowness of LPub on Windows 7


Re: Slowness of LPub on Windows 7
#16
I'm not sure this issue was ever fully resolved other than the advice to use the new 64-bit build of LDView 4.2 Beta. Last Friday I posted the following elsewhere due to an issue I was having:

Quote:Sadly, the problem has resurfaced, but at least I was able to gather a lot of new information for help in troubleshooting.

I’m on a Windows 7 machine with brand new installs of the LDraw library, LPub, and the 64-bit build of LDView 4.2beta referenced above. I’ve done many instructions with this setup already and had no problems whatsoever. Some of the models were very large (over 1 Mb MPD files) and with hundreds of pages. No problem. Then something changed.

I am working a new set of instructions and everything was going fine. Then I get to Page 57 and for some reason everything just stopped. Data I’ve gathered:
  • If I simply open the model in LDView 4.2b in the GUI, it takes about 30 seconds to load and display. No errors or problems.
  • The above consumes about 250 Mb of RAM.
  • When LPub calls LDView to make an image of this model (and keep in mind these are early steps so it is not even the whole model), LDView consumes on average 500 Mb of RAM.
  • When LPub calls LDView to make a parts list image (single part), it only takes about a second. A view of the whole model takes about 30 seconds.
  • As of page 57, a call to LDView initially consumes about 500 Mb of RAM up until the point that it should return the image, then it suddenly consumes 4.7 Gb of RAM (all available) and the hard drive light goes steady “ON” implying even more virtual memory is called.
  • Entire computer locks (can’t even move mouse) until process completes. This takes 1-2 hours.
  • There is nothing special about page 57. In fact, this is a submodel step with only 5 parts in it so it should take seconds.
  • Subsequent pages after this have the same problem. Model and computer are completely unusable.
  • No other model died at Page 57. No changes to computer configuration. This happened in the middle of working a model.
  • Restart of the computer or LPub has no effect.
Questions:
  • Why does LDView use more RAM when called from LPub than it does to open the entire model in GUI?
  • Why does it consume 4.5 Gb of RAM on Page 57 when the whole model can be loaded for 250 Mb?
  • How am I supposed to finish these instructions? ;-)
Any help would be greatly appreciated. I’m sure that tracking this down will be no small task, but it seems like if this is solved it will reveal a lot that may be of future value.

I've been working with Travis on trying to figure out the issue, but as you can see the 64-bit build did not solve the issue in this case. I have an open action to try a custom build that Travis gave me which will log the commands sent to LDView to see if that helps.

In the interim, I wanted to point out that I've found a partial solution:
Quote:I've made a discovery. I was messing around with the preferences trying to figure out why the log file wasn't working. I decided to try just using a different preference set, so I made one with most options shut off (no lighting, shading, anti-aliasing, primitive sub, etc.). To my surprise, LPub now works fine and I am able to get past the previous crashing point. Using process of elimination, I should be able to gradually add features back in and see what was causing the problem.

It is still odd because that's the same pref set I used for my other instructions and had no problems, and it is the same set I used up until Page 59. It is also the same set I used in the GUI without problems. Something must be different about the image export as opposed to the OpenGL display.

I thought the community would be interested in this since I can't be the only one having the same problem.

Eric
Reply
« Next Oldest | Next Newest »



Messages In This Thread
Slowness of LPub on Windows 7 - by Bill Ward - 2012-03-05, 22:51
Re: Slowness of LPub on Windows 7 - by Eric Albrecht - 2012-06-25, 19:46

Forum Jump:


Users browsing this thread: 3 Guest(s)