Automapper: Performance?

[Mike-E-angelo]

I was recently pointed out to another mapping library, Mapster, which has some metrics on performance vs. AutoMapper:

https://github.com/eswann/Mapster

I am curious if this is a known issue and/or if this is something that is planned to be addressed in future versions.

FWIW, I am not planning to switch because I am lazy. :) Also my current codebase is meant more for proof of concept rather than production at the moment so not exactly critical. I am more curious than anything at this point.

[jbogard]

First, I mainly use LINQ projections which is faster than any of the
benchmarks shown. I use AutoMapper from entities from a database, where the
time spent mapping is a fraction of a percent of the overall request. And
comparing to other mappers, well, extra features cost with performance.
Things with more features, and especially flexibility, will be slower.

My suggestion is look at the overall cost in your app, not in a benchmark
but a real app, to see what the performance cost will be.

I do look at performance, and generally increasing performance means
removing quite a large amount of features and flexibility. So I opt for
good-enough since for me the bottleneck in my apps is nearly always the
network hop to the database.

On Sunday, January 31, 2016, Mike-EEE [email protected] wrote:

I was recently pointed out to another mapping library, Mapster, which has
some metrics on performance vs. AutoMapper:

https://github.com/eswann/Mapster

I am curious if this is a known issue and/or if this is something that is
planned to be addressed in future versions.

FWIW, I am not planning to switch because I am lazy. :) Also my current
codebase is meant more for proof of concept rather than production at the
moment so not exactly critical. I am more curious than anything at this
point.

—
Reply to this email directly or view it on GitHub
https://github.com/AutoMapper/AutoMapper/issues/1067.

[Mike-E-angelo]

OK cool. Works for me. Might be nice to have something in the Wiki regarding this too, as I am sure I am not the only one who will have this question (especially for those who are doing the analysis), and also, it will save you a few keystrokes for the next time someone asks. :)

[TylerCarlson1]

The big difference in performance is most the others use Expressions, which is what ProjectTo does and is faster, although limited in what it supports because of EF and NHibernate.

So unless you app is a benchmark app, or you are translating 100,000's of in memory object back and forth there's not a significant benefit to it.

That being said I was looking at making a PR for it, but I don't know how feasible it is to make expressions to speed things up AND keep all the existing functionality working as intended.

[jbogard]

Especially debugging and troubleshooting. The biggest perf hit are creating
all those ResolutionContext things. If something goes wrong, and you don't
have that, you've got basically zero way of troubleshooting it.

Though I think if I can get the readonly configuration right, it should be
easy to look at a given map and come up with a plan based on what you've
configured. And you just would get no feedback if it goes belly up.

Someone asked if I could use Roslyn to build up the plan, that's possible
too. But it's also impossible to debug/troubleshoot an object initializer,
the fastest way of building, because it's just one statement.

On Sun, Jan 31, 2016 at 1:56 PM, Tyler Carlson [email protected]
wrote:

The big difference in performance is most the others use Expressions,
which is what ProjectTo does and is faster, although limited in what it
supports because of EF and NHibernate.

So unless you app is a benchmark app, or you are translating 100,000's of
in memory object back and forth there's not a significant benefit to it.

That being said I was looking at making a PR for it, but I don't know how
feasible it is to make expressions to speed things up AND keep all the
existing functionality working as intended.

—
Reply to this email directly or view it on GitHub
https://github.com/AutoMapper/AutoMapper/issues/1067#issuecomment-177597353
.

[TylerCarlson1]

Didn't think about resolution context. ResolutionContextPool or caching ResolutionContext then?

[TylerCarlson1]

OMG that's a lot of ResolutionContexts created. Yea that's yer problem right there

[jbogard]

GEE THANKS SHERLOCK.

I'm finishing up the read only profile stuff now, that could be something
to look at next, just creating one context per map operation or something.
It does bother me how bloated that thing has become.

On Sunday, January 31, 2016, Tyler Carlson [email protected] wrote:

OMG that's a lot of ResolutionContexts created. Yea that's yer problem
right there

—
Reply to this email directly or view it on GitHub
https://github.com/AutoMapper/AutoMapper/issues/1067#issuecomment-177740806
.

[TylerCarlson1]

One thing could be to update the context map instead of generating a new one with property maps. Once you map a property or update the context of said property the old one isn't needed anymore. It passed so no need for debugging info about it

So ResolutionContext.CreateNewContext could be replaced with ResolutionContext.UpdateContext and stop all the new statements.

[jbogard]

Or introducing logging for purposes of debugging. I'm open to anything,
really.

Then you have people using the context to walk the parent chain of objects,
doing crazy stuff like that.

For even more fun, check out the collection mappers, they create a context
per item in a collection. A dumb feature I added for the wrong reasons
years ago.

On Mon, Feb 1, 2016 at 10:21 AM, Tyler Carlson [email protected]
wrote:

One thing could be to update the context map instead of generating a new
one with property maps. Once you map a property or update the context of
said property the old one isn't needed anymore. It passed so no need for
debugging info about it

So ResolutionContext.CreateNewContext could be replaced with
ResolutionContext.UpdateContext and stop all the new statements.

—
Reply to this email directly or view it on GitHub
https://github.com/AutoMapper/AutoMapper/issues/1067#issuecomment-178052261
.

[lbargaoanu]

Logging is more difficult to use. Troubleshooting through exceptions seems way better to me.

[TylerCarlson1]

Or just have CreateMissingMapTypes on all the time. Everything can map to everything. No more missing type map exceptions. Problem solved.

[jbogard]

Latest 5.0 drop is about 10x faster than previous version.

Also 10x slower than Mapster, because AutoMapper gathers a lot more context information for debugging/troubleshooting purposes in the resulting expression. Mapster just generates a plain expression, so if anything goes wrong you have....nothing to go off of.

[Mike-E-angelo]

I hate to suggest it... but perhaps making it configurable to optimize the expression? Basically a "release" version of the expression(s) and a "debug" (current, as designed) version?

[jbogard]

Ugh. Well, I could see an explicit config, "disable diagnostics" or similar.

Open a new GH issue?

[Mike-E-angelo]

Sure thing, boss! :sunglasses: https://github.com/AutoMapper/AutoMapper/issues/1285

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.