Pages: 1
Print
Author Topic: 100% cpu on on output dalog  (Read 7933 times)
gcrews
Member

Posts: 265


« on: August 16, 2010, 02:53:07 PM »

I’m not sure if this is something that I caused or by an update. XMetaL Version#: 6.0.0.122

Suddenly whenever I try and generate an output after pressing “OK” in the generate output dialog.  XMetaL processes goes to 50% cpu usage on my dual core. The toolkit kicks off and runs and everything, but XMetaL is locked up. I was using the generate output just fine Friday afternoon and was only working with the xsl for pdf output. I did load about 15 windows updates onto my computer Friday before I left.  Is anyone else experiencing similar problems?

ps: I know one of the updates was http://support.microsoft.com/kb/983583
Update: A complete reinstall of XMetaL 6.0 did not help.

Update 2: After a restart, the first time I opened the Xmetal installer started running again and now it doesn’t lock up.  I restarted Monday morning after all the updates so I’m not sure why a restart today worked or why the Xmetal installer kicked off again.  Guess my computer had a case of the Mondays.
« Last Edit: August 18, 2010, 10:01:29 AM by gcrews » Logged
gcrews
Member

Posts: 265


« Reply #1 on: August 27, 2010, 10:38:12 AM »

Ok the problems kind of back, but not on the output dialog.  I’ve been trying to work with a few DITA maps the past couple of days. The maps are kind of big with about 1000 topic refs to html files. I used to be able to edit and work with them fine. Now for some reason Xmetal bogs down on them like no buddies business. The take 20 seconds to open. When I try and save it pretty much locks up going at full CPU.  Sometimes just clicking somewhere in the document makes Xmetal go berserk.  Any Ideas? I even tried turning off while you type spell checking but that did not help anything.

Update: After about 5 min of going 100% Xmetal finally saved the document. I think I figured out what is gobbling up so much CPU while saving.  Comparing the text of the saved file to another copy, Xmetal added class="- map/topicref " and all the extra class junk to the ditamap. It’s doing that on topic files and stuff to now when I save. Is there some option that I somehow checked in Xmetal that no turned on that is now adding all that stuff to all the documents I save and taking a lot more CPU usage?  I looked at some of the attached dlls to Xmetal and saw that it looks like that .NET update updated a few dlls Xmetal uses. The System.xml one seems a bit interesting. I think that controls some of the xml serialization and stuff.


* usage.jpg (123.18 KB, 1052x515 - viewed 771 times.)

* dll.jpg (101.52 KB, 1185x87 - viewed 763 times.)
« Last Edit: August 27, 2010, 11:25:59 AM by gcrews » Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2621



WWW
« Reply #2 on: August 27, 2010, 11:57:15 AM »

@class values should not be being added, and we don't have a setting (as far as I know) that would trigger that. We do have a setting in Tools > DITA Options that unhides the class attribute in the Attribute Inspector to let you see what the current value is and change it if you like (not recommended). However, that does not add the value to the document unless you actually make a change. What you see by default in the Attribute Inspector is the class value extracted from the DTD. You should be able to confirm that by switching to Plain Text view. In your case you can't trust that as the value might already be coded after saving, in which case deleting the value, then switching back and forth between Plain Text and Tags On should remove the value and then show you what is declared as in the DTD.

We use MSXML for some operations and some other parsers as well for other things. So, it is possible that an MS update might change some behavior and that is what I am suspecting right now. Or it might be some other control that MS has changed the behavior for.

I'll see if I can reproduce this. Please let me know if this looks like it would be close:

1) Install XMetaL Author Enterprise 6.0.0.122 on a clean XP machine.
2) Open one of our sample maps in Tags On view. I assume you are using a regular map and not bookmap? These two things (the type of map and the view) might make a difference so please let me know.
3) Add a reference to a topic (so I can save) then Save the map.
4) Store this map for future reference as "normal" behavior.
5) Install patch http://support.microsoft.com/kb/983583
6) Redo steps 2 and 3.
7) Compare the maps to see if that patch is triggering your issue.
« Last Edit: May 19, 2011, 03:23:35 PM by Derek Read » Logged
gcrews
Member

Posts: 265


« Reply #3 on: August 27, 2010, 12:25:37 PM »

@class values should be being added

should  or should not?
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2621



WWW
« Reply #4 on: August 27, 2010, 12:33:56 PM »

Sorry, that's definitely 'should not'.

I'm in the process of setting up a machine. I've needed to add one step as a clean install of XP doesn't include .NET runtime and the MS patch is specifically for that.

I've already completed testing without .NET installed and @class is not being added, so that's expected behavior.

One more thing, is a CMS involved? Scripts that connect XMetaL with a CMS could also alter the save behavior.
Logged
gcrews
Member

Posts: 265


« Reply #5 on: August 27, 2010, 12:46:17 PM »

Ok, now it’s not doing it. I completely uninstalled Xmetal 6.0, rebooted, and then reinstalled again as I did about a week ago when the dialog box was going nuts. No CMS involved. I’m not sure what changed, I will let you know if it comes back. I can’t think of anything that I had tweaked or changed in Xmetal since the last reinstall that would have caused the issue.
« Last Edit: August 27, 2010, 01:00:29 PM by gcrews » Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2621



WWW
« Reply #6 on: August 27, 2010, 02:06:54 PM »

I cannot reproduce it (ie: @class are not being added) with .NET 3.5 SP1 + KB983583 installed -- my steps listed in my post from 11:57:15.

Given that and that it seems to be intermittent for you I think we're looking at something else. Can you give some exact steps and info on your configuration that might differ from a default install? The most likely thing I can think of still is that you have a Macro installed that is doing something to cause the problem. The most likely source for such a script would be the installation of a CMS integration or an integration with some other 3rd party software.
Logged
gcrews
Member

Posts: 265


« Reply #7 on: September 20, 2010, 01:53:21 PM »

It's back, it seems to most commonly happen on Mondays. Any ideas to tests before I restarting my computer?


* 9-20-2010 12-42-52 PM.png (5.49 KB, 579x176 - viewed 723 times.)
Logged
Derek Read
Program Manager (XMetaL)
Administrator
Member

Posts: 2621



WWW
« Reply #8 on: September 20, 2010, 03:06:47 PM »

I'm not sure. Are your input files stored locally? What about the output file location?

If a network is involved that might have something to do with it. Perhaps the machine you store files on gets really busy at particular times and that comes back to affect XMetaL, forcing it to wait for read/writes to complete or something.

If something else was affecting this on your local machine it might not be noticable CPU-wise. Maybe look for somethink like that (some virus scanners, back-up programs and disk cleaners can use almost no CPU power but high amounts of disk reads/writes). I had a machine a while ago that had virus scanning software configured to run first thing Tuesdays and it took me a while to figure out because CPU usage was very low but HDD reads were very high slowing everything else down (particularly Outlook which just sat there at a crawl because my PST files are quite big).
Logged
Pages: 1
Print
Jump to: