Date: Fri, 05 Oct 2007 15:30:47 +0200
Paul Sandoz wrote:
> Here is another result for a different set of randomly generated data
> for the same size. This time i am warming up for 30s and running for 20s
> (the latter is important especially for fast implementations to get a
> good average).
>
> I will do another one with a another set of data for the same
> measurement configurations...
>
And one more... last one i promise!
Nice work Frank,
Paul.
> Paul.
>
> Jakub Podlesak wrote:
>> Hi Paul,
>>
>> please see in line...
>>
>> On Fri, Oct 05, 2007 at 12:57:34PM +0200, Paul Sandoz wrote:
>>> Jakub Podlesak wrote:
>>>> Hi Frank,
>>>>
>>>> Very impressive results! Congratulations.
>>>>
>>> Yes. It looks very promising. I am going to send am email out talking
>>> about the whole URI resolving aspects and how we may proceed forward.
>>>
>>>
>>>> And it is interesting,
>>>> that for the medium set (50 uris) the result is always
>>>> better than for the small sets (20 uris).
>>> Do you mean the other way around? The larger the bar the better the
>>> result.
>>
>> no, i mean the following (differencies are more apparent for the
>> linear driver):
>>
>> Linear Driver:
>> time result
>> Small set (20 templates) right handed 12.279 0.407
>> Medium set (50 templates) right handed 7.782 0.643 (bigger
>> set, better result)
>>
>> Small set (20 templates) right slashed 12.369 0.404
>> Medium set (50 templates) right slashed 8.081 0.619 --"--
>>
>>
>> Trie Driver:
>>
>> Small set (20 templates) right handed 0.047 105.875
>> Medium set (50 templates) right handed 0.039 129.814 --"--
>>
>> Small set (20 templates) right slashed 0.037 133.742
>> Medium set (50 templates) right slashed 0.036 137.403 --"--
>>
>>
>>> It is tricky to compare results between different sets because each
>>> set uses different input data (although the size is the same) and
>>> different URI templates. Plus the linear algorithm could potentially
>>> terminate on average less than for other tests depending on the set
>>> of URIs.
>>
>> Absolutely. The important thing is that Frank's algorithm is much better
>> than the linear one.
>>
>>>
>>>> Did you try yet another different uri sets? And different uri set
>>>> sizes (200, 500)?
>>>>
>>> Frank gave me the source for the drivers and i modified to test 2 4 8
>>> 16 32 64 128 templates using the same set source source data (reduced
>>> in size but i increased the number of warmup and run iterations). I
>>> plotted this of a log log scatter graph (see attached).
>>
>> Nice graph.
>>
>> ~Jakub
>>
>>> As you can see there is variance between linear and Trie between sets
>>> of data but the clear trend is that:
>>>
>>> 1) Trie is always faster;
>>>
>>> 2) Linear degrades when the number of templates increases;
>>>
>>> 3) Trie displays good scalability as the number of templates
>>> increases; and
>>>
>>> 4) Trie can get an order of magnitude better than linear for small
>>> sets of templates e.g. 8 templates.
>>>
>>> Paul.
>>>
>>>> ~Jakub
>>>>
>>>> On Thu, Oct 04, 2007 at 05:42:11PM -0500, Frank Martínez wrote:
>>>>> Hi all guys,
>>>>>
>>>>> I have made some benchmarkings with TrieUriPathResolver and
>>>>> LinearOrderedUriPathResolver.
>>>>>
>>>>> Look some results in the (attached) japex report.
>>>>> Please read the (attached) README file before.
>>>>>
>>>>> Regards,
>>>>>
>>>>> --
>>>>> Frank D. Martínez M.
>>>>> Asimov Technologies Ltda.
>>>>> Blog: http://www.ibstaff.net/fmartinez/
>>>>
>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>>>>
>>> --
>>> | ? + ? = To question
>>> ----------------\
>>> Paul Sandoz
>>> x38109
>>> +33-4-76188109
>>>
>>
>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
>>> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
>> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
>>
>
>
> ------------------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: dev-help_at_jersey.dev.java.net
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109
(image/jpeg attachment: testcase0.jpg)