Now I'm ready for the nanoseconds. Why doing this? Because it's cheap doing it with the automated inlining tool I have built.

You know that the time you spent actually developing this tool and feeding your code into it probably outweighs any such performance benefit by a factor of hundreds, right?

Unless you spent less than a couple seconds or so developing this tool, you've already wasted your time working on something that is costing more time and effort than it is saving you. And that's without paraphrasing the above members with your fundamentally broken optimization approach.

Let's see, it took me about 10 months to produce 9,000+ effective lines of code, and I expect to produce twice as much when I finish the project. Starting took me more effort (more time thinking on future implications, and less code production) because I was building the foundations. I'm making the optimization workflow part of the foundation, so I can define the guidelines to write further code and get the most of source processing. Now, it took me 1 week to build, test and fix the inlining tool in Perl. The tool takes around 3 seconds to shave these 9,000+ lines of code. Now, by defining the optimization guidelines I can put the razor aside, and work normally. That means I don't shave until the next 18,000+ lines. I'll get a Duck Dynasty's beard, but I can always shave at the end without cutting my nose It's a good moment to optimize.

There is no design flaw.

How naive...

You know enough to say that there will always be boxing/unboxing in non-trivial code but fail to realize that any non-trivial code will have design flaws or at the very least, sub-optimal design trade-offs.

Of all the possible performance improvements in C#, boxing is like 10th in modern codebases. Have you curtailed your allocations? Have you chosen the right collections/algorithms? Have you pre-allocated your collections? Have you looked into pre-JITing to your target platform? Have you looked to parallelize/memoize your common algorithms?

Have you actually compiled in release mode and benchmarked the differences?

Look OP: you may be right, but understand that we see literally hundreds of people coming in here complaining of performance issues or claiming they NEED to do these things that the best of the best universally see as frivolous. We're just playing the odds that you're not the sub-one percent that really do need to do these things...

It amazes me that I never received a straight answer to my question, which I considered pretty basic. Some commenters had the genuine intention of guiding me, thinking that there is a flaw since they really don't have a full picture of the system. I can understand that, but then many are just repeating the concerns of others, and are poisoning the thread to the extreme that my words are being taken out of context to produce more concern. Now you ask for an effort on my side to further explain my design... you haven't done a single effort to answer my question, so you get nothing. In conclusion all this evasion from my question leads me to believe that it's difficult to achieve full statement-to-expression with C#'s non-overridden operators, and that saves me some time investigating them actively, I'll do it passively. I'll determine if the task is impossible later on. Answering all your concerns I was able to proof test my system's design. Also, now I know that not many developers will adventure in this field due to the "don't program that way or I hit you with a stick" mentality. Answers were helpful but only indirectly, the thread will be closed since it's already poisoned. Thanks