--- title: "Managed C++ performence vs. native C++" url: "https://osherove.com/blog/2003/7/16/managed-c-performence-vs-native-c.md" canonical: "https://osherove.com/blog/2003/7/16/managed-c-performence-vs-native-c.html" published: "2003-07-16T17:49:00" updated: "2003-07-16T17:49:00" tags: [".Net Original"] author: "Roy Osherove" description: "The user group meeting today went great. Very interesting stuff. We actually got to see all the stuff that the .Net framework installation installs on the target machine. Lot’s of goodies in there right out of the box.…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # Managed C++ performence vs. native C++ By Roy Osherove July 16, 2003 In [.Net Original](https://osherove.com/blog/category/net-original) **Historical article** · Originally published July 16, 2003; technical details may be outdated. The user group meeting today went great. Very interesting stuff. We actually got to see all the stuff that the .Net framework installation installs on the target machine. Lot’s of goodies in there right out of the box. One of the things that interested me the most of a discussion about Managed C++ and how it compares to native C++ performance wise(It wasn’t the subject but it was still a C++ user group at the core so the discussion shifted several times). It was interesting to me because although I’m not a C++ developer (but I’ll have to be soon, yey!), I got into an argument with one of my colleagues. He claims(even though he has no real experience in .Net and he admits to only hearing it from other “certified” sources) that managed C++ will always be slower than native C++ because of several facts: 1)      The virtual machine gets in the way 2)      Security checks and others being performed before the code is actually executed. In response I said that he’s talking nonsense, and that I know for a fact that Managed C++ can be much faster then native, and I had several points to that: 1)      JIT compilation before execution allows for optimized code to run against the current machine configuration and CPU(a Pentium 4,for example, has an optimized set of instructions for floating point operations I think). 2)      Um.. that was what I could come up with. As a matter of fact, I stood there, without the ability to defend  what I believed to be true, because I had no real reinforcement in terms of optimizations. His arguments did make sense and I started to think that perhaps I was wrong? Then to my rescue the subject came up at the user group and the speaker was damned straight about it – Managed C++ on average, can outperform the C++ optimizer on standard applications. The main reasons: 1)      JIT compilation – like what I said before 2)      Memory allocation. This was a point I had not considered.  The CLR allocates memory in a much different and faster way then the C++ memory allocation scheme. Basically in native C++ the memory allocation scheme had to look for a place in which to put memory chunks in(I won’t go into much detail here), when in the CLR the memory is always allocated without looking for free space. It just “puts” it on top (or at the end of) the memory chain and garbage collection later comes into play and removes any “holes” between chunks. This essentially is a much faster operation(not garbage collection, just memory allocation. GC is very expensive). In the end, the CLR optimizations easily compensate for the other “slow” features. So yeah, Managed C++ can be much faster then native. Cool! Update: [This post from Brad Adams](http://blogs.gotdotnet.com/BradA/permalink.aspx/a4ff32cf-1285-4ab1-95b8-7f7a45d467a0) helps clear things up even more! ## More in .Net Original [All posts in .Net Original](https://osherove.com/blog/category/net-original) - Jul 21, 2003 ### [Kit George on BitVector32 bug](https://osherove.com/blog/2003/7/21/kit-george-on-bitvector32-bug.html) - Jul 17, 2003 ### [Your favorite add-in?](https://osherove.com/blog/2003/7/17/your-favorite-add-in.html) - Jul 15, 2003 ### [.Net articles on MSDNAA](https://osherove.com/blog/2003/7/15/net-articles-on-msdnaa.html) - Jul 14, 2003 ### [More maintainable code(and others) lessons](https://osherove.com/blog/2003/7/14/more-maintainable-codeand-others-lessons.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/