Well done .NET!...
-
For my own pet project to take over the world in my spare time, I was, this week, rewriting a BinarySerializer from scratch. Almost there, only "the Deserializer left to do". I'm caching dynamically generated method to access all field, I did a good encoding. In my little serializing (only so far) tests I was 20% smaller than the .NET default serialization! :-) Out of curiosity I just did a speed test... Ho man... The build in .NET serialization is .... 12 times faster! :sigh: (i.e. what I do in 12 seconds, they do in just 1, just be unambiguously clear). How could they do that! It's so unfair! :omg: Ho well I will just go with the default serialization and try to work around the little issue it has... And... well done the .NET team! :cool:
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
For my own pet project to take over the world in my spare time, I was, this week, rewriting a BinarySerializer from scratch. Almost there, only "the Deserializer left to do". I'm caching dynamically generated method to access all field, I did a good encoding. In my little serializing (only so far) tests I was 20% smaller than the .NET default serialization! :-) Out of curiosity I just did a speed test... Ho man... The build in .NET serialization is .... 12 times faster! :sigh: (i.e. what I do in 12 seconds, they do in just 1, just be unambiguously clear). How could they do that! It's so unfair! :omg: Ho well I will just go with the default serialization and try to work around the little issue it has... And... well done the .NET team! :cool:
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
So what's the problem with the default one? I've hit a few issues myself and always managed to get around them...:cool:
-
So what's the problem with the default one? I've hit a few issues myself and always managed to get around them...:cool:
2 issues: 1. it throws exceptions when deserializing (if there is a problem) (while I was planning to simply drop value) (but because it is so fast to start with, that's not really a problem) 2. It serialize whole object, in my serializer I was adding an option to drop any object of ignored type (as defined by the user). The idea was to drop delegates! Why that? I'm writing a modular application which takes 3rd party data and serialize them. I don't want to have inappropriate data due to dangling event handler... if I just drop them the 3rd party developer will quickly realize the problem during his tests. But comes to think of it, UI element are not serializable. That will throw exception during the save process and hint the developer to fix that. And remove a big chunk of typical event listener source. Maybe it's not all so bad... mmm.... Now, anyway, I'd like to know how come they do that so fast!!!! maybe I could improve the speed with some security demand? This was a very teaching experience so far (my 1st emit code! :-) )
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
So what's the problem with the default one? I've hit a few issues myself and always managed to get around them...:cool:
3. there is no serializer in Silverlight! but Emit and Reflection do exist! So I can use my serializer on silverlight! :-) And it is supposed to serialize as well as the .NET one!
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
2 issues: 1. it throws exceptions when deserializing (if there is a problem) (while I was planning to simply drop value) (but because it is so fast to start with, that's not really a problem) 2. It serialize whole object, in my serializer I was adding an option to drop any object of ignored type (as defined by the user). The idea was to drop delegates! Why that? I'm writing a modular application which takes 3rd party data and serialize them. I don't want to have inappropriate data due to dangling event handler... if I just drop them the 3rd party developer will quickly realize the problem during his tests. But comes to think of it, UI element are not serializable. That will throw exception during the save process and hint the developer to fix that. And remove a big chunk of typical event listener source. Maybe it's not all so bad... mmm.... Now, anyway, I'd like to know how come they do that so fast!!!! maybe I could improve the speed with some security demand? This was a very teaching experience so far (my 1st emit code! :-) )
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
Super Lloyd wrote:
I'd like to know how come they do that so fast
Do you really think .NET is written in .NET? Or the (much faster) native code? :laugh:
No trees were harmed in the sending of this message; however, a significant number of electrons were slightly inconvenienced. This message is made of fully recyclable Zeros and Ones
-
Super Lloyd wrote:
I'd like to know how come they do that so fast
Do you really think .NET is written in .NET? Or the (much faster) native code? :laugh:
No trees were harmed in the sending of this message; however, a significant number of electrons were slightly inconvenienced. This message is made of fully recyclable Zeros and Ones
Well, most .NET is written in .NET! (Except some very low level building block..) But anyway, from a quick look in Reflector, it looks like the .NET Serialization in indeed written mostly in .NET (and use heaps of classes!)
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
3. there is no serializer in Silverlight! but Emit and Reflection do exist! So I can use my serializer on silverlight! :-) And it is supposed to serialize as well as the .NET one!
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
Do people actually use that cruft (Silverlight)?
-
Do people actually use that cruft (Silverlight)?
I am. I'm currently learning it, but the project I will work on will be coded with Silverlight3, RIA Services and Prism. Not my choices, but I'm happy to learn new stuff after almost 3 years of doing boring .NET 2.0 console apps.
-
Do people actually use that cruft (Silverlight)?
Well, while my spare time pet project to take over the world is still a while away, I'm already thinking to have a Silverlight we demo! Other than that in my work we just started to investigate Silverlight for some stuff. I should say I'm disappointed so far that much desktop code can't just be recompiled under silverlight, maybe I was hoping for too much... Maybe XBAP is more appropriate for us... Anyway, mmh... not that I have used it.. but I bought the marketing pitch! :-) Yea, I know, I'm soo naive! :laugh:
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
Do people actually use that cruft (Silverlight)?
BTW Silverlight 3 is way more modern than Silverlight 1 (or even 2)
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
So what's the problem with the default one? I've hit a few issues myself and always managed to get around them...:cool:
I wrote my own some time ago because back then the compact framework didn't have serialization. I'd expect the default one to be faster really, it's probably written at least partially in C/C++ with some slowing safety checks switched off and optimized well as it's expected to be used in a lot of places, etc. I've never been in a situation where the performance (either of the default or of my custom) has been an issue though so haven't ran any speed tests.
-
BTW Silverlight 3 is way more modern than Silverlight 1 (or even 2)
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
Super Lloyd wrote:
BTW Silverlight 3 is way more modern than Silverlight 1 (or even 2)
I have a (bad) habit of looking a MS technologies when they first come out. A couple of days invested there seems like a good plan. Unfortunately, MS has this tendency to "reinvent" the technology and just up the version number (and make the product actually good!). And here I am stuck with my 1.0 impressions :sigh: I actually had someone tell me that Sharepoint was actually usable now! Now you're telling me that Silverlight is at least "OK"! I guess it's time to take another look.
-
I wrote my own some time ago because back then the compact framework didn't have serialization. I'd expect the default one to be faster really, it's probably written at least partially in C/C++ with some slowing safety checks switched off and optimized well as it's expected to be used in a lot of places, etc. I've never been in a situation where the performance (either of the default or of my custom) has been an issue though so haven't ran any speed tests.
I'm not at the point where I could make an informed statement (for my pet project in my spare time to take over the world), however all the data would be saved by using serialization (not the whole data at once, mind you, just chunks of it. but all of it in chunk). Hence I guess the faster the better to provide a snazzy user experience. A x10 speed difference is a clear no brainer!
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
Super Lloyd wrote:
BTW Silverlight 3 is way more modern than Silverlight 1 (or even 2)
I have a (bad) habit of looking a MS technologies when they first come out. A couple of days invested there seems like a good plan. Unfortunately, MS has this tendency to "reinvent" the technology and just up the version number (and make the product actually good!). And here I am stuck with my 1.0 impressions :sigh: I actually had someone tell me that Sharepoint was actually usable now! Now you're telling me that Silverlight is at least "OK"! I guess it's time to take another look.
BruceCarson wrote:
And here I am stuck with my 1.0 impressions
That would be bad with Silverlight since it did not have .NET included in 1.0, just Javascript :)
Rocky <>< Recent Blog Post: Chocolate Chip Cookies!
-
2 issues: 1. it throws exceptions when deserializing (if there is a problem) (while I was planning to simply drop value) (but because it is so fast to start with, that's not really a problem) 2. It serialize whole object, in my serializer I was adding an option to drop any object of ignored type (as defined by the user). The idea was to drop delegates! Why that? I'm writing a modular application which takes 3rd party data and serialize them. I don't want to have inappropriate data due to dangling event handler... if I just drop them the 3rd party developer will quickly realize the problem during his tests. But comes to think of it, UI element are not serializable. That will throw exception during the save process and hint the developer to fix that. And remove a big chunk of typical event listener source. Maybe it's not all so bad... mmm.... Now, anyway, I'd like to know how come they do that so fast!!!! maybe I could improve the speed with some security demand? This was a very teaching experience so far (my 1st emit code! :-) )
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
What I always do is this to not serialize event handlers (but not sure if this is what you were looking for):
\[field: NonSerialized\] public event EventHandler Modified;Wout
-
Do people actually use that cruft (Silverlight)?
No. It is used to play videos on web pages. That is about it.
I didn't get any requirements for the signature
-
What I always do is this to not serialize event handlers (but not sure if this is what you were looking for):
\[field: NonSerialized\] public event EventHandler Modified;Wout
Doing that you control the serialization of your classes. But in my case I want to drop delegate from 3rd party data structure! I can't tag their code! ;)
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
For my own pet project to take over the world in my spare time, I was, this week, rewriting a BinarySerializer from scratch. Almost there, only "the Deserializer left to do". I'm caching dynamically generated method to access all field, I did a good encoding. In my little serializing (only so far) tests I was 20% smaller than the .NET default serialization! :-) Out of curiosity I just did a speed test... Ho man... The build in .NET serialization is .... 12 times faster! :sigh: (i.e. what I do in 12 seconds, they do in just 1, just be unambiguously clear). How could they do that! It's so unfair! :omg: Ho well I will just go with the default serialization and try to work around the little issue it has... And... well done the .NET team! :cool:
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
welcome to the bizzaro lounge. :cool:
jim
-
For my own pet project to take over the world in my spare time, I was, this week, rewriting a BinarySerializer from scratch. Almost there, only "the Deserializer left to do". I'm caching dynamically generated method to access all field, I did a good encoding. In my little serializing (only so far) tests I was 20% smaller than the .NET default serialization! :-) Out of curiosity I just did a speed test... Ho man... The build in .NET serialization is .... 12 times faster! :sigh: (i.e. what I do in 12 seconds, they do in just 1, just be unambiguously clear). How could they do that! It's so unfair! :omg: Ho well I will just go with the default serialization and try to work around the little issue it has... And... well done the .NET team! :cool:
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
Super Lloyd wrote:
How could they do that! It's so unfair!
Run ILDasm and find out how they did it :)
-
For my own pet project to take over the world in my spare time, I was, this week, rewriting a BinarySerializer from scratch. Almost there, only "the Deserializer left to do". I'm caching dynamically generated method to access all field, I did a good encoding. In my little serializing (only so far) tests I was 20% smaller than the .NET default serialization! :-) Out of curiosity I just did a speed test... Ho man... The build in .NET serialization is .... 12 times faster! :sigh: (i.e. what I do in 12 seconds, they do in just 1, just be unambiguously clear). How could they do that! It's so unfair! :omg: Ho well I will just go with the default serialization and try to work around the little issue it has... And... well done the .NET team! :cool:
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
Are you using c++ and memory mapped IO?
Need custom software developed? I do C# development and consulting all over the United States. A man said to the universe: "Sir I exist!" "However," replied the universe, "The fact has not created in me A sense of obligation." --Stephen Crane
