Given the existing encorder was not put behind any sort of interface (the
impl is directly used), it's proving to be a PIA to track down all the
different types and changing them to use the new codec.
Look at the "public static void register(Decoder decoder, EncoderImpl
encoder)" method of any of the XXXType classes to get a sense of what I'm
describing.

We should take this opportunity to review the current approach and see if
we could come up with a better alternative.
If anybody has any suggestions, I would be happy to discuss them with you
on the list.

Regards,

Rajith




On Thu, Jan 15, 2015 at 3:15 PM, Rafael Schloming <r...@alum.mit.edu> wrote:

> I don't believe there is an existing one.
>
> --Rafael
>
> On Thu, Jan 15, 2015 at 3:10 PM, Rajith Muditha Attapattu <
> rajit...@gmail.com> wrote:
>
> > Rafi,
> >
> > Do you have a JIRA for this work?
> >
> > Regards,
> >
> > Rajith
> >
> > On Wed, Jan 14, 2015 at 6:35 PM, Rajith Muditha Attapattu <
> > rajit...@gmail.com> wrote:
> >
> > > Rafi,
> > >
> > > I had a closer look at the code, put it on trunk and ran your
> benchmark.
> > > I see quite an improvement with respect to writing lists, maps and
> > strings.
> > >
> > > Simply put the writeList and writeMap methods in the old encorder is
> > about
> > > ~10 times slower than the new encorder.
> > > If I run with a sufficiently large set of strings, the old encorder is
> > > about ~2 times slower than the new encorder.
> > >
> > > I'm now focusing on hooking it up with the engine.
> > >
> > > Once that is done we can look at tweaking it further. But as it is, the
> > > new codec is a real improvement over the existing one.
> > > Great job Rafi!
> > >
> > > Rajith
> > >
> > > On Tue, Jan 6, 2015 at 10:28 AM, Rajith Muditha Attapattu <
> > > rajit...@gmail.com> wrote:
> > >
> > >> Thanks Rafi, for the link.
> > >> I agree that any work should use this as a basis.
> > >>
> > >> I plan to take a closer look at this in the next week or so.
> > >>
> > >> Rajith
> > >>
> > >> On Wed, Dec 17, 2014 at 1:24 PM, Rafael Schloming <r...@alum.mit.edu>
> > >> wrote:
> > >>
> > >>> A while back I implemented a relatively complete standalone codec
> here:
> > >>>
> > >>>
> > >>>
> > >>>
> >
> https://github.com/rhs/qpid-proton-old/tree/codec/proton-j/src/main/java/org/apache/qpid/proton/codec2
> > >>>
> > >>> It's quite a bit faster than the existing codec. I believe any new
> > codec
> > >>> work should probably be based on this. It's relatively standalone, so
> > >>> should be easy to import into the tree, and then it's just a matter
> of
> > >>> modifying the rest of the engine to use it. Note that my
> > qpid-proton-old
> > >>> repo is a clone of the pre-migration repo.
> > >>>
> > >>> --Rafael
> > >>>
> > >>>
> > >>> On Mon, Dec 15, 2014 at 2:17 PM, Rajith Muditha Attapattu <
> > >>> rajit...@gmail.com> wrote:
> > >>> >
> > >>> > I'm starting to look at improving this areas as I was told a few
> > folks
> > >>> have
> > >>> > noted some concerns.
> > >>> >
> > >>> > I would appreciate some input on these concerns and hope to have a
> > >>> > discussion to figure out how best to proceed.
> > >>> >
> > >>> > Regards,
> > >>> >
> > >>> > Rajith
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>

Reply via email to