Oh makes total sense. But just so I understand. This could be used in
multiple threads if someone instantiates this serializer and uses it in two
Kryo instances running concurrently. Is that right? So are you thinking
thread local variables? Or should I just go back to your original idea of a
pool like you did for JavaSerializer?


On Tue, Jan 7, 2014 at 3:07 PM, Nathan Sweet <notifications@github.com>wrote:

> In src/com/esotericsoftware/kryo/serializers/ExternalizableSerializer.java:
>
> > +        this.checkForReplaceMethods = checkForReplaceMethods;
> > +    }
> > +
> > +    @Override
> > +    public void write( Kryo kryo, Output output, Object object ) {
> > +        JavaSerializer serializer = getJavaSerializer( object.getClass() );
> > +        if ( serializer == null ) {
> > +            writeExternal( kryo, output, (Externalizable)object );
> > +        }
> > +        else {
> > +            serializer.write( kryo, output, object );
> > +        }
> > +    }
> > +
> > +    protected void writeExternal( Kryo kryo, Output output, Externalizable object ) {
> > +        ObjectOutput objectOutput = new KryoObjectOutput( kryo, output );
>
> It mostly comes with my writing libs for Android, where GC has a large
> penalty. It's a hard thing to microbenchmark since it involves GC. I think
> moving the KryoObjectOutput to a field and a setter (or two) for the Kryo
> and Output/Input instance is easy enough. No need to pool. read/write can
> be reentrant, but are single threaded and nested calls will set the same
> instances.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/EsotericSoftware/kryo/pull/167/files#r8710611>
> .
>