I think it may be valuable for you if you give more detail on what type of object conversion you are performing here.
Measuring elapsed time using DateTime is well-known to be "limited" in accuracy. Starting with .NET 2.0, you can use the 'StopWatch in the System.Diagnostics library timer to get more accurate results: [^].
Executing the code several times before starting a timing operation is also believed to improve timing accuracy by eliminating any possible one-time costs of getting the code "jitted."
There are several articles here on CodeProject dealing with accurate timing: just search.
“The best hope is that one of these days the Ground will get disgusted enough just to walk away ~ leaving people with nothing more to stand ON than what they have so bloody well stood FOR up to now.” Kenneth Patchen, Poet
Sorry - didn't mean to insult in no way - However, measuring is not the issue here - i am quite sure with the results since the times of the operations are long (~10 seconds) because the objects contains a lot of data - it is not milliseconds of difference.
The problem is that i want to convert objects without knowing its members - it should be done using their names (one property data in object one is copied to object two's property which has the same name).
using serialization i can serialize one object from one module to an object of another module easily.
I was looking for a way to serialize from one object to another without using a memory stream in the middle - that will solve my problem.
After checking AutoMapper i realized that i need to specifically map all internal types of the objects from source to target. this requires as my objects can contain many types and it will require a LOT of work (not to mention maintenance as they change) before it can be used and i need something to do the conversions automatically with minimal work => leads me to my first posted code.
So i return to the original question - is it possible to skip the MemoryStream read/write?
is it possible to skip the MemoryStream read/write?
Only if you write mappings for each internal object.
My philosophy is to build Clone() methods for each object (class), and call them for nested objects as required. Implementing Clone() is easily done by calling .NET's MemberwiseClone() for most properties. You will find the effort required to do this small in comparison to the run-time performance gain.
If you have a generalized object graph and a need to map any type of object to any other type, I would like to suggest that you revisit your design. Object mapping is mostly used when converting DTOs to business objects, and frameworks like Automapper and Fasterflect prove to be very convenient (and fast) in these cases.
If you choose to go with your existing design, you may want to consider XmlSerializer which caches serializers for different types, causing a one-time performance hit on first convert. But this is also not as performant as simple mapping.
I want to call web api from desktop application .
For that I use readasync method . Using readasync method, pass multiple parameters as a concatenated string. In webapi I split that string in to multiple parameters. How can I pass multiple parameters from c# application?
How can i benefit from SQL CLR C# stored procedure or any item like this in SQL Server Project vi vs2013...I need some information about the benefit and use of this project in windows application project.Please i need an overview about this type of project and what its usefulnes....Thank you
We do not do your homework: it is set for a reason. It is there so that you think about what you have been told, and try to understand it. It is also there so that your tutor can identify areas where you are weak, and focus more attention on remedial action.
Try it yourself, you may find it is not as difficult as you think!
I'm pretty sure your tutor wants to know what you think about this, not what I think...
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)