The primary reason automapping is slower is that it does not cache the
mappings. Doing so creates concurrency challenges and also introduced the
notorious "remapResults" configuration switch in iBATIS 2.
I figure, if you want performance, map all of your results explicitly, and
turn of auto mapping (NONE). If you want simplicity, set it to PARTIAL. If
you have a pain fetish, set it to FULL.
Cheers,
Clinton
On Tue, Feb 2, 2010 at 1:28 PM, Stephen Friedrich <
stephen.friedr...@fortis-it.eu> wrote:
> Thanks for the quick response. Yes, I was looking for release notes
> somewhere close to the download link, but haven’t found any.
>
> Setting FULL did the trick.
>
>
>
> I had just started to evaluate performance anyway because first results on
> the integration server were not so great:
>
> A simple web service method (JAX-RS) that reads a thousand rows, then
> serializes that to JSON (no collections involved) takes two seconds.
>
> Now looking at some profiling results in YourKit I see that
> FastResulSetHandler.applyAutomaticMappings() alone takes up more than half
> of the total web service time:
>
>
>
> [I tried to send a screenshot here, but the mail was rejected due to
> suspected spam]
>
> 56% FastResultSetHandler.applyAutomaticMappings()
>
> 18% MetaObject.findProperty()
>
> 16% MetaClass.buildProperty()
>
> 13% Reflector.findPropertyName()
>
> 10% String.toUpperCase()
>
> …
>
>
>
> I already patched Reflector.findPropertyName() so that the calls to
> toUpperCase() are avoided, using an additional map:
>
> public String findPropertyName(String name) {
>
> // return caseInsensitivePropertyMap.get(name.toUpperCase());
>
> String propName = propertyMap.get(name);
>
> if (propName == null) {
>
> propName = caseInsensitivePropertyMap.get(name.toUpperCase());
>
> if (propName != null) {
>
> propertyMap.put(name, propName);
>
> }
>
> }
>
> return propName;
>
> }
>
> That is noticeably better - most of all on the real web server, which is a
> quite dated Sparc T2000 with horrible single-thread performance.
>
> However I feel that much better performance gains should be reachable on a
> higher abstraction level.
>
>
>
> Is there a conceptual reason why automatic mapping should be noticeably
> slower than explicit mapping?
>
> That should only make a difference for the first request, shoudn’t it?
>
>
>
> Stephen
>
>
>
> *Von:* Clinton Begin [mailto:clinton.be...@gmail.com]
> *Gesendet:* Dienstag, 2. Februar 2010 16:47
> *An:* user-java@ibatis.apache.org
> *Betreff:* Re: regresssion (?) in beta 9: No automapping if some
> properties are explicitly mapped
>
>
>
> Sorry, this was a change. See the documentation for <settings> in the user
> guide. Unfortunately I poorly advertised the change.
>
> You can now configure the setting autoMappingBehavior="NONE|PARTIAL|FULL"
>
> NONE and FULL are pretty self explanatory. FULL is how it worked in
> previous betas. However, the new default is PARTIAL, which means that
> automapping only happens on simple, flat queries. If you use associations
> or collections, PARTIAL mode will not automap fields.
>
> The primary reason was that I found when doing complex joins, it was hard
> to tell where the value would end up, especially in cases where the column
> matched multiple property names in parent and child objects. So I chose
> PARTIAL to be a happy medium between simplicity and expressiveness. But if
> you're confident that your unit testing will deal with any uncertainty, then
> feel free to set it to FULL. Otherwise, I suggest sticking with PARTIAL.
> There is also an obvious performance benefit to setting it to PARTIAL or
> NONE.
>
> Cheers,
> Clinton
>
> On Tue, Feb 2, 2010 at 7:26 AM, Stephen Friedrich <
> stephen.friedr...@fortis-it.eu> wrote:
>
> I wonder if this was an intentional change:
>
> My mapping config looks like this:
>
>
>
> <resultMap id="partSetMap" type="PartSetDto">
>
> <id property="id" column="id"/>
>
> <collection property="parts" ofType=" PartDto">
>
> <result column="part_id" property="id" javaType="Long"/>
>
> <result column="serial_no" property="serialNo"
> javaType="String"/>
>
> <result column="is_reserved" property="isReserved"
> javaType="boolean"/>
>
> </collection>
>
> </resultMap>
>
>
>
> <select id="selectPage" resultMap="partSetMap">
>
> …
>
>
>
> PartSetDto has lots of other properties than “id”.
>
> In beta 8 those were automatically filled by naming convention.
>
> In beta 9 all other fields are empty.
>
>
>
>
>
