Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance difference between v1.8.3 and v1.9.1 #149

Open
SteveWilkes opened this issue Feb 20, 2018 · 2 comments
Open

Performance difference between v1.8.3 and v1.9.1 #149

SteveWilkes opened this issue Feb 20, 2018 · 2 comments

Comments

@SteveWilkes
Copy link

Hi,

I've got an ongoing mapper performance project, and it looks like something happened to ExpressMapper between versions 1.8.3 and 1.9.1 which made it much slower mapping non-simple mappings, possibly collections. The two tests in question are:

  • Complex mapping - deep cloning a Foo POCO with various kinds of value type properties, multiply-recursive Foo, List and Foo[] properties, and IEnumerable and int[] properties. For 1 million mappings, this has gone from 14.15s to 103.57s

  • Deep mapping - mapping a POCO with nested POCO and POCO collection properties onto a differently-typed POCO with corresponding properties. For 1 million mappings, this has gone from 6.25s to 94.19s

I'm intending to write a follow-up blog with updated performance results, so wanted to give you a heads up about this before I do.

All the best,

Steve Wilkes

@anth12
Copy link

anth12 commented Mar 22, 2019

They aren't strictly like-for-like, take for example ExpressMapper vs AutoMapper; the AutoMapper registration is cfg.CreateMap<Foo, Foo>() whereas the ExpressMapper registration uses custom Member mappings e.g. .Member(foo => foo.Foos, foo => foo.Foos != null ? foo.Foos.Map<List<Foo>, List<Foo>>() : new List<Foo>()).

I tried running the tests and do get very high times for ExpressMapperComplexTypeMapper & ExpressMapperDeepMapper, however when removing the custom member mappings to make it a fair test with the others (and removing the assertions) I get the following results.

AutoMapperComplexTypeMapper 9.8261461
ExpressMapperComplexTypeMapper 143.674907

AutoMapperDeepMapper 1.4314013
ExpressMapperDeepMapper 133.096825

With custom member mappings removed:

AutoMapperComplexTypeMapper 10.4125455
ExpressMapperComplexTypeMapper 6.3748084

AutoMapperDeepMapper 1.3606325
ExpressMapperDeepMapper 1.9715963

It seems there is a performance issue but it looks isolated to custom member mappings.

@SteveWilkes
Copy link
Author

Hi!

Thanks for the info!

I added the collection member mappings to create empty collections instead of leaving the properties null. For example in the Deep mapper test, if I map new Customer { Name = "Steve" } to a CustomerDto, the result object's Addresses and AddressesArray are both null with ExpressMapper, but populated with empty collections with AutoMapper and AgileMapper.

I may well have not done it in the best way - is there a better way you can suggest?

Cheers,

Steve

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants