LDraw.org Discussion Forums
Slowness of LPub on Windows 7 - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: LDraw Programs (https://forums.ldraw.org/forum-7.html)
+--- Forum: LDraw File Processing and Conversion (https://forums.ldraw.org/forum-22.html)
+--- Thread: Slowness of LPub on Windows 7 (/thread-3576.html)

Slowness of LPub on Windows 7 - Bill Ward - 2012-03-05

Ever since I was issued a new laptop from work and installed lpub on it, it takes ages to do any kind of render operation. I am guessing there's some security setting in Windows that has to time out every time it invokes the external program to do the render. Anyone know how to fix this?

Re: Slowness of LPub on Windows 7 - Travis Cobbs - 2012-03-05

You aren't the first person to encounter this, but I was never able to track down the source of the problem. (I'm guessing you're using LDView as LPub's renderer; if you're using POV-Ray, then that would indeed be slow.) On some systems, LDView takes a long time to exit once it's done creating the image; I couldn't figure out why, and it didn't do this on my Win 7 computer.

You might try temporarily disabling User Account Control (UAC) to see if it solves the problem. I'm not promoting this as a solution, but if it does solve the problem, it would at least tell me where to look. Having said that, LDView shouldn't do anything that requires admin privileges.

Re: Slowness of LPub on Windows 7 - Bill Ward - 2012-03-05

Maybe Windows thinks it requires admin privileges because it writes files? Does it write temp files in a directory that might be protected? It doesn't give me that dialog box to continue when a privileged action is being done, like you see when installing/upgrading software for example.

Re: Slowness of LPub on Windows 7 - Travis Cobbs - 2012-03-06

If all it's doing is writing files to a privileged directory, the files should end up getting written using the shadow file system, so appear to get written to a protected directory, while really getting written somewhere else. I don't know where LPub sends the files generated by LDView; hopefully it either sends them to temp or to somewhere in the user's directory (like AppData). However, if it writes to the LPub directory, I suppose that could create additional slowness for the faked out writes. It might also write somewhere that is a sub-directory of the LDraw directory, so check to see if your LDraw directory itself is in a protected directory.

When I stated that LDView should never need admin rights, I missed pointing out that when it downloads unofficial parts, they always get put into the Unofficial subdirectory of the LDraw directory, so if the LDraw directory itself is somewhere protected, the faked out file writing will happen there also.

One other possible source of the LDView problem is that LDView itself may be incorrectly repeatedly downloading unofficial parts when run from LPub. That would slow things down greatly. I can't remember if I fixed that problem before or after LDView 4.1 was released. You can try this development build of LDView if you want:

http://www.halibut.com/~tcobbs/ldraw/private/LDView-4101-35.zip

Re: Slowness of LPub on Windows 7 - Bill Ward - 2012-03-06

Nope, it's still about the same. I didn't time it, but it doesn't seem to be any faster.

Re: Slowness of LPub on Windows 7 - Bill Ward - 2012-03-06

OK maybe it's a little faster ... but still a pretty long delay to render.

Re: Slowness of LPub on Windows 7 - Travis Cobbs - 2012-03-07

Just to verify (based on your other post), your tests weren't run with the temp files going in a DropBox directory, were they? I could conceivably see that slowing things down a lot.

Re: Slowness of LPub on Windows 7 - Bill Ward - 2012-03-07

Yes, but Dropbox is asynchronous - it's a normal filesystem that Dropbox monitors for changes, not a mounted filesystem.

Re: Slowness of LPub on Windows 7 - Bill Ward - 2012-03-07

To reiterate - I downloaded the version you linked to, and ran it in My Documents instead of Dropbox, and had no major improvement in perceived speed. There might have been some improvement but if so it wasn't much.

Also, I was running it under my VPN for work which requires HTTP proxy for Internet access, so it would probably not have been able to contact the server if it were downloading parts. I just tried it without the VPN and no proxy needed, and it's still slow, so I don't think that's it. Anyway, my parts library contains all the parts in the model.

I still think it's something dumb Windows is doing. Maybe it's the 64 bit vs 32 bit thing. Do you have a 64 bit build of LDView?

Re: Slowness of LPub on Windows 7 - Bill Ward - 2012-03-07

I even tried it on a FAT-formatted USB-mounted disk, hoping that getting out of NTFS-land would fix it, but it still seems quite slow.

Re: Slowness of LPub on Windows 7 - Travis Cobbs - 2012-03-07

Thanks for the clarification, and further verification.

It's quite a bit older, and much more experimental, but here is a 64-bit Windows LDView build:

http://www.halibut.com/~tcobbs/ldraw/private/LDView64-4101-25.zip

Note: since the executable is LDView64.exe, you might have to rename it to LDView.exe in order to get it to be used by LPub.

One other thing to try would be to disable LDView auto-checking of unofficial parts (on the Updates tab of preferences). Please note that even if you have the parts on your computer, LDView will still periodically check for updates to them if they reside in the <LDraw>\Unofficial\Parts directory. So, while it doesn't appear that's the source of the problem, disabling that feature in LDView would rule it out entirely.

Re: Slowness of LPub on Windows 7 - Travis Cobbs - 2012-03-07

Note: if the 64-bit build helps, let me know, and I'll do an updated build to bring it up to date with the 32-bit build.

Re: Slowness of LPub on Windows 7 - Bill Ward - 2012-03-07

The way I use unofficial parts is to import them into the MPD file, so I don't think that's relevant. Only official parts are imported from my parts library.

Re: Slowness of LPub on Windows 7 - Bill Ward - 2012-03-08

I got it running on my Mac and it works great .. in fact I get better PDF results on the Mac with LPub than on Windows! I would expect it to be the same. I used the PDF to OpenOffice Draw plugin to load the results into OpenOffice and make some tweaks, and the Bricks by the Bay event kit instructions are done finally!!

Re: Slowness of LPub on Windows 7 - Matija Puzar - 2012-04-01

Hello Bill,

here is the executable I am using. I had made no changes whatsoever, I just imported the source into the IDE on a Windows 7 64bit, compiled it, and it worked immediately - let me know if it works for you.

http://matija.no/files/LDView.zip


Kind regards,
Matija

Re: Slowness of LPub on Windows 7 - Eric Albrecht - 2012-06-25

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