incubator-directmemory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Manzke <daniel.man...@googlemail.com>
Subject Re: Just to keep discussions alive...
Date Mon, 20 Feb 2012 15:30:14 GMT
raf is right. The size is also an interesting factor. Maybe a test against
a heap-only version where you can see the effect of GC.

2012/2/20 Raffaele P. Guidi <raffaele.p.guidi@gmail.com>

> +1 for benchmarks and I suggest to push them a bit further - testing with
> 2/8/16gb buffers (DirectMemory is about handling huge quantities of RAM,
> after all)
>
> Ciao,
>    R
>
> On Mon, Feb 20, 2012 at 4:19 PM, Daniel Manzke <
> daniel.manzke@googlemail.com
> > wrote:
>
> > I think there is more need for benchmarks.
> >
> > Benchmarks:
> > - read only with a filled cache
> > - read/write in different scenarios (80/20,60/40,40/60,20/80)
> > - read/write with different values sizes (1, 10, 100kb and file sizes
> like
> > 1,5,100mb)
> > - concurrency benchmarks
> >   - requesting the same value
> >   - writing the same value
> >   - writing while requesting it
> >   - ...
> >
> >
> > Bye,
> > Daniel
> >
> > 2012/2/20 Simone Tripodi <simonetripodi@apache.org>
> >
> > > Hi all guys,
> > >
> > > a lot of new ideas and contributions have joined DM in the last days -
> > > and thanks all for participating, that means that the community is
> > > healthy! :) - I would encourage anyway you all on closing some pending
> > > arguments, before that discussions arrive to nowhere.
> > >
> > > I tried to put (almost, apologize in advance if I forgot something,
> > > that was not intentional!) all of them in a kind of "priority queue"
> > >
> > > on core module:
> > >
> > >  * as Daniel suggested on JIRA, put/update methods shall be unified, a
> > > la java.util.Map#put(K, V);
> > >  * as Daniel suggested on JIRA, Serializers have to (de)serialize
> > > directly on/to ByteBuffer instances, rather than manipulating byte[];
> > >  * access directly to the stored ByteBuffer: actually current impl is
> > > a turnaround that created a little of confusion on the following
> > > point;
> > >  * Generics: there is the general agreement to have a Cache<K, V>;
> > >  * Michael suggested concurrency and lower level stuff, hopefully will
> > > contribute some patches;
> > >  * APIs: couldn't resist, actual signatures are IMHO confusing (the
> > > order matters!) so a decision has to be taken to switch or not to
> > > fluent APIs, or at least review the original one.
> > >
> > > plugins/integrations
> > >
> > >  * Karaf: Ioannis is taking care of it;
> > >  * Solr: I was no longer able to run it on my local machine, I hope
> > > TomNaso will have some spare time to help;
> > >  * EHCache: fine, still to be imported (subjected to core
> modifications)
> > ;
> > >  * more serializers: Kryo, ..., for benchmarks (?!?);
> > >  * Olivier's REST server (in progress).
> > >
> > > Does it look complete?
> > >
> > > TIA,
> > > Simo
> > >
> > > http://people.apache.org/~simonetripodi/
> > > http://simonetripodi.livejournal.com/
> > > http://twitter.com/simonetripodi
> > > http://www.99soft.org/
> > >
> >
> >
> >
> > --
> > Viele Grüße/Best Regards
> >
> > Daniel Manzke
> >
>



-- 
Viele Grüße/Best Regards

Daniel Manzke

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message