Re: Profiling OJB
Hi, Edson Carlos Ericksson Richter wrote: Hi! I'm running OJB under NetBeans 5.0 final with JDK 1.5.0_06 and NetBeans Profiler 5.0, OJB 1.0.3. I just run the app, and I see RepositoryPersistor.readMetadataFromXML(org.xml.sar.InputSource, class) is called twice, taking incredible 5561 ms for execution (a 2780ms per call). It's number two for time startup problems in my app: the first one is ClassHelper.getClass(String, boolean), who takes 9913 ms over 4520 invocations (so I think it's ok, about 2.1 ms per call). My question isn't why so longer readMetadataFromXML, but why twice? It's because OJB once read the persistent object metadata (RepositoryXmlHandler) and then the connection metadata mapping (ConnectionDescriptorXmlHandler). It would be possible to do this in one class (this was the case in older OJB versions), but I separated this stuff to make things more clear (servicing classes with nearly 1500 LOC isn't easy). For OJB 1.x the complete metadata handling rework is on the roadmap. If you could provide a faster metadata handling/reading or some optimization for 1.0.x, please let me know. regards, Armin Any tips? Richter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Profiling OJB
Hi! I'm running OJB under NetBeans 5.0 final with JDK 1.5.0_06 and NetBeans Profiler 5.0, OJB 1.0.3. I just run the app, and I see RepositoryPersistor.readMetadataFromXML(org.xml.sar.InputSource, class) is called twice, taking incredible 5561 ms for execution (a 2780ms per call). It's number two for time startup problems in my app: the first one is ClassHelper.getClass(String, boolean), who takes 9913 ms over 4520 invocations (so I think it's ok, about 2.1 ms per call). My question isn't why so longer readMetadataFromXML, but why twice? Any tips? Richter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Profiling OJB
Edson Carlos Ericksson Richter wrote: Sorry, I can't understand what do you mean with "fields that correspond to field descriptors". Today, I have a set/get method for each field in my VO (value object) classes. Almost every one is a direct mapping from set/get to field. What is the impact over my source code to use direct access and/or auto-proxy? I need to make fields public? If you have a real field - as opposed to say, a get and set method that map to something more complicated - then you could be able to use the direct-access impl. This then depends on whether you have security restrictions e.g. in a app server, because the direct access uses reflection instead of bean-property handling as in the introspector-impl. It does not require the field to be public or protected, but for non-public fields there can be a java-security restriction connected to this (which also somehow can be turned off). If you have a mixed scenario (real fields and also properties) then you should use the auto-proxy impl (the name is a bit misleading) which automatically chooses the best impl (direct, introspector, etc.) for each field (actually for each field descriptor, so not much overhead) upon first access to the field. Of course you is right. Time spent in each call is really small (about - average - 39,86 ms for setValueFor and 43,09 ms for getValueFrom - but I still fell it's high). Hmm, yes, try the direct impl, it should be faster. Also, in the dev-archive there should be a post from Armin about the timings he achieved with the new impls, which you can check with your findings. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Profiling OJB
Sorry, I can't understand what do you mean with "fields that correspond to field descriptors". Today, I have a set/get method for each field in my VO (value object) classes. Almost every one is a direct mapping from set/get to field. What is the impact over my source code to use direct access and/or auto-proxy? I need to make fields public? Of course you is right. Time spent in each call is really small (about - average - 39,86 ms for setValueFor and 43,09 ms for getValueFrom - but I still fell it's high). Thanks for fast response. Richter Thomas Dudziak escreveu: Edson Carlos Ericksson Richter wrote: I'm just testing our large app using NetBeans Profiler (JFluid), and found that most time my app is spending in setValueFor (41%) and getValueFrom (13%) in PersistentFieldIntrospectorImplNew class. Someone knows if any other Persistent* class is faster? The question is: how long does it spend on average in these methods ? If this time is small, then you problem is probably elsewhere. Also, if you have fields that correspond to the field descriptors, then you can use the direct-access impl or the auto-proxy impl which delegates to the introspector or direct-access impl depending on the field. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Profiling OJB
Edson Carlos Ericksson Richter wrote: I'm just testing our large app using NetBeans Profiler (JFluid), and found that most time my app is spending in setValueFor (41%) and getValueFrom (13%) in PersistentFieldIntrospectorImplNew class. Someone knows if any other Persistent* class is faster? The question is: how long does it spend on average in these methods ? If this time is small, then you problem is probably elsewhere. Also, if you have fields that correspond to the field descriptors, then you can use the direct-access impl or the auto-proxy impl which delegates to the introspector or direct-access impl depending on the field. Tom - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Profiling OJB
Hi! I'm just testing our large app using NetBeans Profiler (JFluid), and found that most time my app is spending in setValueFor (41%) and getValueFrom (13%) in PersistentFieldIntrospectorImplNew class. Someone knows if any other Persistent* class is faster? Thanks for any info share, Edson Richter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
