History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: CASTOR-2112
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Critical Critical
Assignee: Werner Guttmann
Reporter: Carlo Romero
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
castor

Major performance slowdown unmarshalling between version 0.9.4.3 and 1.1.2.1

Created: 10/Aug/07 11:06 AM   Updated: 14/Mar/08 06:41 AM
Component/s: None
Affects Version/s: 1.1.2.1
Fix Version/s: 1.2

Time Tracking:
Original Estimate: Not Specified
Remaining Estimate: 0 minutes
Time Spent - 2 hours, 50 minutes
Time Spent: 2 hours, 50 minutes
Time Spent - 2 hours, 50 minutes

File Attachments: 1. Text File patch.c2112.20070825.txt (3 kb)

Environment: Linux, Windows XP


 Description  « Hide
When unmarshalling several documents, we noticed a slowdown on the order of 14 times and more between Castor 0.9.4.3 and Castor 1.1.2.1. We didn't see this slowdown in version 1.1.1. It looks like this perfomance degradation was introduced in 1.1.2.1.

 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Werner Guttmann - 13/Aug/07 03:20 AM
Without further information, this is going to be hard to analyze. I've had already had a detailed look at the release notes starting at 1.1.1, and I did not see a single commit set that might cause such an order of slow-down. One thing that came to my attention is that we have switched logging to commons-logging (and as such either Java logging or log4j or whatever you are using)., As such, this slowdown might be caused by excessive logging to e.g. stdout or a file (in case you happen to be using e.g. a FileAppender with log4J). If this is the case, I'd be interested to learn whether changing the log level to e.g. warn or error does cause a change in runtime behavior.

Werner Guttmann - 22/Aug/07 03:10 AM
Just to make a few things clear. After a few conversations with the reporter (off-line, that is), it turns out that the problem reported is related to validation only. If validation is (selectively) turned off, the slowdown vanishes and normal performance is restored.

I am currently in the process of profiling a test case, and will report any findings in due time.


Jim Procter - 22/Aug/07 08:54 AM
I thought that I noticed a significant performance degradation when I put in my patches to 1.1.1 relating to proper hashCode calculation and cyclic references in the XML document (http://jira.codehaus.org/browse/CASTOR-2012). This is unlikely to be the cause, but may have exacerbated the situation. The slow down is definitely on validation, and this is now turned off in our application - but I'd really like to turn it back on!

Following the lines of enquiry begin in http://jira.codehaus.org/browse/CASTOR-1985, I noticed that the ValidationContext class holds sets of objects being validated in a HashSet, rather than using the org.castor.util.IdentitySet. Changing this appeared to slightly improve the speed of marshalling and unmarshalling (we still validate on unmarshalling). I suspect there are a few other cases where this is occuring.


Werner Guttmann - 25/Aug/07 04:32 PM
Initial patch for review.