Do you think I could just leave this part blank and it'd be okay? We're just going to replace the whole thing with a header image anyway, right?
You are not logged in.
Pages: 1
What is Decorator?
Decorator allows you to take an object array and serialize it to a class, with the help of magical attributes.
What can it be used for?
Decorator can be used to ensure type safety on your recieved messages, as well as use regular properties instead of having to use m.GetInt() or other stuff.
Is it PlayerIOClient specific?
No, you can use it in other projects as much as you'd like - it's abstracted all down to BaseMessage
Can you show me an example?
Sure, though everything you need to know is on the github readme
https://gist.github.com/SirJosh3917/a6e … 91b90efeb7
Github repo?
Decorator (click)
Offline
I recreated your library in order to demonstrate my point, and hopefully inspire you to write cleaner and less convoluted code.
The library you wrote contains over a thousand lines of code, not including test projects.
The library I wrote contains a mere ~300 lines of code, and on top of that is (on my **** dual-core CPU) over 3x as fast as your library.
The benchmark you gave me was between 2 and 3 seconds for 100,000 messages and mine does it on my dirt cheap CPU in about 800 milliseconds.
source: https://gist.github.com/atillabyte/f6f7 … c8e07a9241
I think the concept is mostly good although with one caveat; unlike it's likely aspiration (protocol buffers) it's missing the core component, which is the language neutrality through generated structures.
EDIT: scratch that, I just ran it on my PC with decent specs and it's actually 20 times faster, took only 150ms for 100,000 messages.
EDIT EDIT: jesse ran it and got 70ms, so that's around 40x faster than the benchmark you gave me.
*u stinky*
Offline
~300 lines of code
would like to point out that your syntax places opening brackets on new lines, which gives your code a little disadvantage to ninja's. Doesn't matter here really
Offline
XxAtillaxX wrote:~300 lines of code
would like to point out that your syntax places opening brackets on new lines, which gives your code a little disadvantage to ninja's. Doesn't matter here really
I actually used curly braces on the same line for several years until I learned Python, only then was I realizing that I was substituting my love for elegance for a syntax style in a language where it doesn't truly belong.
*u stinky*
Offline
I recreated your library in order to demonstrate my point, and hopefully inspire you to write cleaner and less convoluted code.
that you definitely did
anyways, because the benchmark metric I gave you was the time it took to deserialize and invoke some methods with code in them, the method execution time took quite a while.
Method | Mean | Error | StdDev | Scaled |
---------------- |-----------:|---------:|---------:|-------:|
Decorator | 5,733.8 ns | 43.22 ns | 36.09 ns | 1.00 |
ProtocolMessage | 902.2 ns | 17.30 ns | 19.23 ns | 0.16 |
I looked into this, and Decorator makes an uncached reflection call, big no-no. After fixing that, Decorator was better then ProtocolMessage!
Method | Mean | Error | StdDev | Scaled | ScaledSD |
---------------- |---------:|----------:|----------:|-------:|---------:|
Decorator | 677.6 ns | 13.087 ns | 15.579 ns | 1.00 | 0.00 |
ProtocolMessage | 884.6 ns | 8.393 ns | 7.440 ns | 1.31 | 0.03 |
It seemed odd that Decorator was faster then ProtocolMessage, so I took a look, and ProtocolMessage also makes an uncached reflection call. After fixing that, ProtocolMessage was back on top of Decorator.
Method | Mean | Error | StdDev | Scaled |
---------------- |---------:|---------:|---------:|-------:|
Decorator | 687.5 ns | 6.893 ns | 5.756 ns | 1.00 |
ProtocolMessage | 298.2 ns | 2.971 ns | 2.481 ns | 0.43 |
All in all, ProtocolMessage is about 57% faster then Decorator at deserialization after the reflection call caching.
I'm certainly looking forward to optimizing Decorator even more to be better.
If you wanna check out the benchmarks yourself, check them out for yourself over here
Note: None of the optimizations for Decorator or ProtocolMessage have been committed to Decorator.Benchmarks
Offline
I updated my library to cache and generally optimize the property setter and now it's running around 170-200ms.
I think the IL could be just taken from the generator and used specifically for that purpose, mostly to save a few more lines. It's still ridiculously small though. at less than 300 lines.
*u stinky*
Offline
Decorator 1.1.0 has been released, featuring:
Major performance improvements (5,000ns to 150ns, in comparison ProtocolMessage is around 180ns)
Hiding lots of stuff that should've been hidden anyways
Cleanup in method usage:
TryDeserializeItem & TryDeserializeItems for deserialization, every other method has been stripped out.
InvokeMethodFromMessage and InvokeMethodFromItem for deserialization and invokation of a DeserializedHandler marked method
SerializeToItem and SerializeToItems method
Offline
I've improved mine once again so it's probably faster than yours now.
*u stinky*
Offline
CODE FIGHT!!!
Offline
I've improved mine once again so it's probably faster than yours now.
yup, ProtocolMessage is roughly at 110ns instead of it's old time of 180ns, beating Decorator by 40ns.
I've also improved mine once again, and it's now a slight bit faster than yours (3-10ns, I've re-run it multiple times and it keeps turning up like that).
pretty much equivalent performance at this point.
Offline
CODE FIGHT!!!
XxAtillaxX wrote:I've improved mine once again so it's probably faster than yours now.
yup, ProtocolMessage is roughly at 110ns instead of it's old time of 180ns, beating Decorator by 40ns.
I've also improved mine once again, and it's now a slight bit faster than yours (3-10ns, I've re-run it multiple times and it keeps turning up like that).
pretty much equivalent performance at this point.
I updated mine once more, should be faster than yours again.
*u stinky*
Offline
I will download the bot if it reaches the speed of -10 ns
Time before becoming a Member - Leaderboard
1. Whirl - 9 months
2. KirbyKareem - 8 months
3. pwnzor - 2.4 months
4. MWstudios - 2 months
5. ILikeTofuuJoe - 1.5 months
Piskel is the best GIF maker I've seen
HG's signature for me - Anatoly's signature for me
The Mashed Potatoes Song - The longest post on EE forums - Play my Minesweeper
Offline
I updated mine once more, should be faster than yours again.
yup, 110ns down to 87ns
Decorator can match your speeds (and be ~5ns faster), but it would have to quit typechecking the object array, which is an optimization I'm not willing to make.
Without type checking
Method | Mean | Error | StdDev | Scaled |
------------------------------ |---------:|----------:|----------:|-------:|
'Simple TryDeserialize' | 82.93 ns | 0.3242 ns | 0.2531 ns | 1.00 |
'ProtocolMessage alternative' | 87.06 ns | 0.4252 ns | 0.3977 ns | 1.05 |
Method | Mean | Error | StdDev | Scaled |
------------------------------ |---------:|----------:|----------:|-------:|
'Simple TryDeserialize' | 81.56 ns | 0.5868 ns | 0.5489 ns | 1.00 |
'ProtocolMessage alternative' | 87.73 ns | 0.3281 ns | 0.2908 ns | 1.08 |
With type checking (note: ProtocolMessage doesn't do type checking )
Method | Mean | Error | StdDev | Scaled |
------------------------------ |----------:|----------:|----------:|-------:|
'Simple TryDeserialize' | 111.43 ns | 0.5202 ns | 0.4611 ns | 1.00 |
'ProtocolMessage alternative' | 86.86 ns | 0.3612 ns | 0.3016 ns | 0.78 |
Method | Mean | Error | StdDev | Scaled |
------------------------------ |----------:|----------:|----------:|-------:|
'Simple TryDeserialize' | 102.15 ns | 0.4296 ns | 0.3354 ns | 1.00 |
'ProtocolMessage alternative' | 87.71 ns | 0.4067 ns | 0.3606 ns | 0.86 |
Offline
Pages: 1
[ Started around 1732368793.2774 - Generated in 0.100 seconds, 12 queries executed - Memory usage: 1.64 MiB (Peak: 1.86 MiB) ]