Hi Marc, Thanks for the response.
Actually, in order for our expectations to meet my applications works in two steps firstly it calculates which element needs to be encrypted and it does that my making a copy of data and once it found the processing instruction it than remembers that the next element is the *only* element to be encrypted .. here is the code: So, basically if there is a PI before <color_swatch> tag than only that particular element will be encrypted and not all the elements that are <color_swatch>'s. I know that xmlsec library works different than this. I buried myself in this code in last few days and I think this performance cannot be improved that's because of following reasons: 1. The more complicated XML structure the more time it will take for processing. 2. It's not encrypted or decryption that takes significant time but its the stream that is being handled after decryption that takes time, if the number of elements are significantly in XML than the stream takes a lot of time. 3. XMLStreamReader that is returned by processInMessage is taking time, I was wrong in thinking that next method of XMLSecurityStreamReader (http://grepcode.com/file/repo1.maven.org/maven2/org.apache.santuario/xmlsec/2.0.0-beta/org/apache/xml/security/stax/impl/XMLSecurityStreamReader.java#XMLSecurityStreamReader.next%28%29) takes lot of time .... but we cannot blame it either as I tried to change the implementation as you suggested (thanks for that) : this also takes almost same amount of time. 4. I think what i can take from this exercise is that we cannot optmize this that's because the way the other implemenations of transfomers "com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl." are also taking same time.. may be i am wrong but this is what i believe at the moment. Please let me know if you have any comments. Thanks a lot. Mujahed -- View this message in context: http://apache-xml-project.6118.n7.nabble.com/Performance-Testing-tp41389p41418.html Sent from the Apache XML - Security - Dev mailing list archive at Nabble.com.
