XML Editor
Sign up for a WebBoard account Sign Up Keyword Search Search More Options... Options
Chat Rooms Chat Help Help News News Log in to WebBoard Log in Not Logged in
Show tree view Topic
Go to previous topicPrev TopicGo to next topicNext Topic
Postnext
Page BasheerSubject: memory management
Author: Page Basheer
Date: 11 Oct 2013 05:16 PM
Hello,
This message is to vent my frustration at the lack of sophisticated Java memory management in your brilliantly engineered product. The fact that you put a burden on potentially Java-challenged users to decide how much memory is required to run a large file is unreasonable. The fact that your product does not simply cure a bad java heap problem, or do an analysis and attempt to predict suitable settings is unreasonable. The fact that you do not produce a 64-bit product is unreasonable.

For what it's worth, Oxygen, even though it has a 64-bit product, andoes a good job of handling huge files, has the same Java memory management lameness.

I'm constantly having to help our (two) other users through this nonsense.

Thanks for letting me vent.

Postnext
Ivan PedruzziSubject: memory management
Author: Ivan Pedruzzi
Date: 11 Oct 2013 08:19 PM
Hi Page,

I understand your frustration unfortunately, there is no single solution to solve everybody memory heap problems.

The Java heap needs to be allocated when the application starts and it cannot be changed after that. When the out memory error occurs, it's too late to recover.

The Java virtual machine has its policy to determine the amount memory to reserve at start-up and on each new version, such policy is tweaked to optimize the trade-off between performance and footprint.
We took the conscious decision to let the JVM decide the initial heap size.

We wish our customer could process all their transformations in stream fashion and, our DataDirect XQuery process does a remarkable job when the conditions allow it. Such transformations run with a fixed amount of memory no matter how big the input document may be.
But not all transformations comply with streaming requirements which force the processor to build the entire DOM in memory.

Yes, Stylus Studio 64 bit is one our highest priority an it will move the boundary quite a bit.

Let us know if we can provide more help and if there is anything else we can improve in the product and we will add it to our TO-DO list


Ivan Pedruzzi
Stylus Studio Team

Posttop
Page BasheerSubject: memory management
Author: Page Basheer
Date: 11 Oct 2013 10:19 PM
Thank you for taking the trouble to respond.

One can understand why it might be difficult to know how much memory might be required for a given task, but maybe some kind of iterative process would be feasible, instead of just putting the burden on the ("Java-unaware/uninformed") user. No doubt limited resources versus higher priorities are at play.

Looking forward to a 64-bit implementation of a great product.


 
Go to previous topicPrev TopicGo to next topicNext Topic
Download A Free Trial of Stylus Studio 6 XML Professional Edition Today! Powered by Stylus Studio, the world's leading XML IDE for XML, XSLT, XQuery, XML Schema, DTD, XPath, WSDL, XHTML, SQL/XML, and XML Mapping!  
go

Log In Options

Site Map | Privacy Policy | Terms of Use | Trademarks
Stylus Scoop XML Newsletter:
W3C Member
Stylus Studio® and DataDirect XQuery ™are from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2016 All Rights Reserved.