Return-Path: 
 <dev-return-13492-apmail-directory-dev-archive=directory.apache.org@directory.apache.org>
Delivered-To: apmail-directory-dev-archive@www.apache.org
Received: (qmail 68384 invoked from network); 9 Sep 2006 13:28:23 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 9 Sep 2006 13:28:23 -0000
Received: (qmail 83584 invoked by uid 500); 9 Sep 2006 13:28:22 -0000
Delivered-To: apmail-directory-dev-archive@directory.apache.org
Received: (qmail 83524 invoked by uid 500); 9 Sep 2006 13:28:22 -0000
Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@directory.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@directory.apache.org>
List-Post: <mailto:dev@directory.apache.org>
List-Id: <dev.directory.apache.org>
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Delivered-To: mailing list dev@directory.apache.org
Received: (qmail 83513 invoked by uid 99); 9 Sep 2006 13:28:22 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 09 Sep 2006 06:28:22 -0700
X-ASF-Spam-Status: No, hits=1.9 required=10.0
	tests=DNS_FROM_RFC_ABUSE,SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (asf.osuosl.org: 212.27.42.27 is neither permitted nor
 denied by domain of elecharny@gmail.com)
Received: from [212.27.42.27] (HELO smtp1-g19.free.fr) (212.27.42.27)
    by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 09 Sep 2006 06:28:21 -0700
Received: from [192.168.0.1] (vol75-3-82-66-216-176.fbx.proxad.net
 [82.66.216.176])
	by smtp1-g19.free.fr (Postfix) with ESMTP id 245B77AAD2
	for <dev@directory.apache.org>; Sat,  9 Sep 2006 15:28:00 +0200 (CEST)
Message-ID: <4502C15F.4060008@gmail.com>
Date: Sat, 09 Sep 2006 15:27:59 +0200
From: Emmanuel Lecharny <elecharny@gmail.com>
Reply-To: elecharny@iktek.com
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923)
X-Accept-Language: fr, en
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [ADS 2.0] New ASN.1 codec metrics
References: <45028FFE.7080009@iktek.com>
 <a1b4a6610609090457j7ab63099td8fb134bea62aa2@mail.gmail.com>
In-Reply-To: <a1b4a6610609090457j7ab63099td8fb134bea62aa2@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Ersin Er a écrit :

> Hi,
>
> On 9/9/06, Emmanuel Lecharny <elecharny@iktek.com> wrote:
>
>> <sqnip/>
>> - Twix : encoding 10 000 000 BindRequest takes 27 seconds
>> - NewTwix : encoding 10 000 000 BindRequest takes 192 seconds 
>
> <snip/>

>> Question : at what point good design is better than performance ?
>
>
> Good design is good and it can be optimized I think. Don't you think
> that there may be some optimization points in the new code?

Yes, for sure. For isntance, the measure was done in Debug mode ... Not 
very good, indeed :)
Now, here are the real values :
- Twix : encoding 10 000 000 BindRequest takes 27 seconds
- NewTwix : encoding 10 000 000 BindRequest takes 64 seconds

This is only ~2.4 times slower. The overcost is mainly due to the 
creation of Decorators and Ber instance of decorators. Without those 
object creations, we would have been as fast.

Ok, now, let's discuss that a little bit. We need decorators, because it 
helps a lot to decouple the data and the logic. We should use them if we 
deliver an API which will be used by client. On the server side, I'm a 
little bit reluctant to use something that cost 2.4 times, when this 
portion of code is so heavily used. But, right now, we can live with 
this result.

We should just keep in mind that there is a margin if we really need to 
improve things :)

If anybody has a better idea than Decorators to design the codec, I will 
be very happy to hear about it. The current design can be seen here :
http://docs.safehaus.org/display/APACHEDS/Message+structure

Emmanuel.
PS: Thanks Ersin to have mentioned a potential optimization :)

>
>> Emmanuel Lécharny
>
>