Added pull request for inclusion of fast serialization.

[Rüdiger Möller]

Currently all serializers run in "unshared references" (no cycle detection) and with preregistered classes. 

I think it would be a good idea to add "default mode" variants for "real serializers" (detect shared refs, no preregistering of classes). 

Detecting cycles and double occurences of the same object makes up to 40% of runtime. Avoiding transmission of unregistered classnames also is an important feature not covered with the current configurations.

What do you think ?

[Tatu Saloranta]

I think that enabling of cycle detection and handling of references is problematic as default setting, as many of frameworks do not really support it. I think having alternate set with full handling would be useful, but changing defaults not (IMO).

As to pre-registration: we have sort of 3 modes (manual, tree-model, automatic), and pre-registration sort of conflicts with fully automated definition; I think optional pre-registration is an optimization that is bit against idea of fully automatic mode. So if library allows automatic detection and pre-registration, there probably needs to be two sub-variants of "automatic". Or just leave out pre-registration, which I think is not allowed as a default (unless library simply won't work without doing that -- and if so, should be noted somehow).

-+ Tatu +-

--
You received this message because you are subscribed to the Google Groups "java-serialization-benchmarking" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java-serialization-be...@googlegroups.com.
To post to this group, send email to java-serializat...@googlegroups.com.
Visit this group at http://groups.google.com/group/java-serialization-benchmarking.
For more options, visit https://groups.google.com/groups/opt_out.

[Rüdiger Möller]

I did not mean to change defaults ofc. Just add a third run using only serializers which are "full" serializers (no pregregistration, cycle detection). I think there are some in the test which do support this (kry, fast-serialization, JBoss serialization (?) and probably some of the jsonish stuff ?)

It would be interesting to see the cost of those features.

Am Mittwoch, 5. März 2014 19:33:37 UTC+1 schrieb cowtowncoder:

I think that enabling of cycle detection and handling of references is problematic as default setting, as many of frameworks do not really support it. I think having alternate set with full handling would be useful, but changing defaults not (IMO).

As to pre-registration: we have sort of 3 modes (manual, tree-model, automatic), and pre-registration sort of conflicts with fully automated definition; I think optional pre-registration is an optimization that is bit against idea of fully automatic mode. So if library allows automatic detection and pre-registration, there probably needs to be two sub-variants of "automatic". Or just leave out pre-registration, which I think is not allowed as a default (unless library simply won't work without doing that -- and if so, should be noted somehow).

-+ Tatu +-

On Wed, Mar 5, 2014 at 9:40 AM, Rüdiger Möller <moru...@gmail.com> wrote:

Currently all serializers run in "unshared references" (no cycle detection) and with preregistered classes. 

I think it would be a good idea to add "default mode" variants for "real serializers" (detect shared refs, no preregistering of classes). 

Detecting cycles and double occurences of the same object makes up to 40% of runtime. Avoiding transmission of unregistered classnames also is an important feature not covered with the current configurations.

What do you think ?

--
You received this message because you are subscribed to the Google Groups "java-serialization-benchmarking" group.

To unsubscribe from this group and stop receiving emails from it, send an email to java-serialization-benchmarking+unsubscribe@googlegroups.com.
To post to this group, send email to java-serialization-benchm...@googlegroups.com.

[Martin Grotzke]

+1, sounds interesting.

To unsubscribe from this group and stop receiving emails from it, send an email to java-serialization-be...@googlegroups.com.
To post to this group, send email to java-serializat...@googlegroups.com.

[Tatu Saloranta]

Ok. As usual, pull requests are a good way to get changes, I think there are a few developers with commit access.
Most changes come from authors of serialization libraries, and although there are occasional discussions on fairness of changes, for the most part I think improvements have been non-controversial.

The main challenge I think is just that of organization; how to keep results relevant when new codecs are added quite frequently; and when we have dozens of potential subsets to test.

-+ Tatu +-

To unsubscribe from this group and stop receiving emails from it, send an email to java-serialization-be...@googlegroups.com.
To post to this group, send email to java-serializat...@googlegroups.com.

[Rüdiger Möller]

I can do that and add a pull request. But first I'd like to see my current pull request being merged. Let me know if you see issues with that. I tested BenchMarkRunner and the Streaming thingy.

Am Donnerstag, 6. März 2014 00:29:56 UTC+1 schrieb cowtowncoder:

Ok. As usual, pull requests are a good way to get changes, I think there are a few developers with commit access.
Most changes come from authors of serialization libraries, and although there are occasional discussions on fairness of changes, for the most part I think improvements have been non-controversial.

The main challenge I think is just that of organization; how to keep results relevant when new codecs are added quite frequently; and when we have dozens of potential subsets to test.

-+ Tatu +-

On Wed, Mar 5, 2014 at 11:32 AM, Rüdiger Möller <moru...@gmail.com> wrote:

I did not mean to change defaults ofc. Just add a third run using only serializers which are "full" serializers (no pregregistration, cycle detection). I think there are some in the test which do support this (kry, fast-serialization, JBoss serialization (?) and probably some of the jsonish stuff ?)

It would be interesting to see the cost of those features.

Am Mittwoch, 5. März 2014 19:33:37 UTC+1 schrieb cowtowncoder:

I think that enabling of cycle detection and handling of references is problematic as default setting, as many of frameworks do not really support it. I think having alternate set with full handling would be useful, but changing defaults not (IMO).

As to pre-registration: we have sort of 3 modes (manual, tree-model, automatic), and pre-registration sort of conflicts with fully automated definition; I think optional pre-registration is an optimization that is bit against idea of fully automatic mode. So if library allows automatic detection and pre-registration, there probably needs to be two sub-variants of "automatic". Or just leave out pre-registration, which I think is not allowed as a default (unless library simply won't work without doing that -- and if so, should be noted somehow).

-+ Tatu +-

On Wed, Mar 5, 2014 at 9:40 AM, Rüdiger Möller <moru...@gmail.com> wrote:

Currently all serializers run in "unshared references" (no cycle detection) and with preregistered classes. 

I think it would be a good idea to add "default mode" variants for "real serializers" (detect shared refs, no preregistering of classes). 

Detecting cycles and double occurences of the same object makes up to 40% of runtime. Avoiding transmission of unregistered classnames also is an important feature not covered with the current configurations.

What do you think ?

--
You received this message because you are subscribed to the Google Groups "java-serialization-benchmarking" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java-serialization-benchmarking+unsubscribe@googlegroups.com.

To post to this group, send email to java-serialization-benchmarking...@googlegroups.com.

Visit this group at http://groups.google.com/group/java-serialization-benchmarking.
For more options, visit https://groups.google.com/groups/opt_out.