[ImageJ-devel] Labeling - Revised Branch

[Tobias Pietzsch]

On 03/20/2012 05:26 PM, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 20 Mar 2012, Tobias Pietzsch wrote:
>
>> The main point for you is, that now you can use "smaller" IntegerTypes
>> (eg. Byte) to store the Labeling, so you save memory, right?
>>
>> That's cool, but it comes with the additional overhead of using a
>> SamplerConverter for the Accessors. So you trade of memory vs computation
>> time.
>
> If I may enter the discussion: it'd be smashing if that trade-off could be
> configured by the caller somehow ;-) Then compute-intensive tasks could
> let ImgLib know that they're interested in saving time, not space. And
> space-intensive tasks could indicate the opposite.

Maybe, you could make LabelingType an interface and provide one 
implementation that is equivalent to the old one, and one implementation 
that uses a TypeConverter to map into arbitrary IntegerTypes?

Also, then we could later add more implementations if they are really 
needed.

That's probably easier said than done, though...


>
>> Did you do any benchmarks to see how much runtime-overhead you have
>> there?
>
> I did a little DuckDuckGo search and it seems as if there is a Performance
> Plugin for Jenkins. It can use the output of JUnit, so maybe it would be a
> fun thing to implement these performance tests as JUnit tests? Then we
> could just configure our Jenkins to test the performance with every new
> commit (or at least with as many as Jenkins catches through polling) and
> see how performance improves...

That would be awesome!
Is there anything special you need to implement, or does it just use 
every test?

>
> Ciao,
> Dscho