Page 1 of 1

writing mode slows down

Posted: Tue Feb 26, 2013 3:26 pm
by QuintusFixlein
Hi,
I am using oXygen 14.2 on W7 and I work on xhtml-webpage via webdav connection to a Tomcat, which worked like a charm. Today, somehow, everything in the editor slowed down and its reaction to typing and deleting is really slow, nearly not usable.
I'm not sure if this has anything to do with the webdav connection since I experienced this problem before with DocBook files (and older versions of oXygen).
My suspicion is that it has something to do with the allocated memory, since the files I work with a (relatively) big and oXygen is using up alot of memory, according to
Process Explorer around 900.000K.
Is there a possibility to allocate more memory to the tool, or is my system memory to small?

Any hint to solve this problem is appreciated!

cheers,
Quintus

Re: writing mode slows down

Posted: Tue Feb 26, 2013 3:59 pm
by adrian
Hello,

Have you tried to restart the application? Does the problem persist after a restart?
Do you have a 64-bit edition of Windows 7? If you do and also have enough RAM installed (4GB or more), you could install and use the 64-bit edition of Oxygen (has more memory available by default, 1500m).

Note that what you see in Process Explorer or the Windows Task Manager is just the memory used by the Java VM that Oxygen runs inside of. This does not reflect the internal memory usage of Oxygen, just the current size (and most likely upper limit) of the Java VM memory.

Starting with v14 a small widget(optional) is available in the Oxygen status bar (bottom right of the application) that shows you the Java heap usage (instantaneous) and also allows you to force a garbage collection to free up the memory and see a value closer the real heap usage. You can enable this from Options > Preferences, Global, Show memory status. This should give you an idea if/when Oxygen reaches the limits of the available memory.

If you want to increase the memory available to Oxygen you should modify the -Xmx parameter in the oxygen14.2.vmoptions file from the Oxygen installation folder. For the 32-bit edition of Oxygen you should use at most -Xmx1200m (this is a limit imposed by the 32 bit architecture and the Java VM overhead). For the 64-bit edition there is no actual limit. However, in either case, we recommended not allocating more than half of the physical RAM for Oxygen.

Restart the application and verify the amount of memory that is actually available to Oxygen in Help -> About, JVM Memory Used/Total(last row). If the application no longer starts and the error message says that it could not start the JVM then you probably went too far (or specified a bad value) and you should decrease the amount of memory in the 'oxygen14.2.vmoptions' file and try again.

In Windows Vista/7 you will first have to copy the oxygen14.2.vmoptions file to your Desktop(or another folder with write access), modify it there and then copy it back to the Oxygen installation folder replacing the original file.

Note that the parameters from the ".vmoptions" file are only used if you start Oxygen with the "oxygen14.2" launcher(or the desktop shortcut). If you are using the command line startup script "oxygen.bat", you should modify the -Xmx parameter in the script file.

Regards,
Adrian

Re: writing mode slows down

Posted: Tue Feb 26, 2013 4:33 pm
by QuintusFixlein
Well, what can I say?
Brillant, comprehensive and successfull answer and suggestions.
Garbage collection did the trick, thanks a lot!

regards,
Quintus

Re: writing mode slows down

Posted: Tue Feb 26, 2013 5:58 pm
by adrian
Hi,

I'd like to point out that manual garbage collection from Oxygen doesn't actually do anything to resolve or improve the insufficient memory problems, it just gives you a better picture of how much memory is actually used by the application.

The manual garbage collection simply triggers the Java VM to perform a memory cleanup that would eventually be triggered anyway when the Java VM runs out of usable (clean) memory. So while the Java VM automatic garbage collection is lazy (it cleans up only if it has to), it always cleans up all the memory it can, before running out of memory. This is why you usually feel that significant slowdown when running close to the Java VM memory limit, the automatic garbage collector is hard at work trying to scrape up any memory it can to make room for the memory allocation requests.

Regards,
Adrian