Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <4039090A.9080006@verizon.net>
Date: Sun, 22 Feb 2004 11:54:50 -0800
From: Christopher Oliver <res1cf5x@verizon.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.6b) Gecko/20031205 Thunderbird/0.4
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Java continuations with joeq
References: <13EA8488-648C-11D8-8E8F-000393CFE402@apache.org>
 <40390795.7090801@verizon.net>
In-Reply-To: <40390795.7090801@verizon.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Christopher Oliver wrote:

> Bertrand Delacretaz wrote:
>
>> Le Samedi, 21 f�v 2004, � 17:13 Europe/Zurich, Christopher Oliver a 
>> �crit :
>>
>>> ...I did some informal tests and it appears to actually be slower 
>>> than interpreted Rhino (not sure exactly why, perhaps because Rhino 
>>> bytecodes are higher level), but was significantly faster than 
>>> BeanShell (which  is a Java source code interpreter).
>>
>>
>>
>> Is it a lot slower, do you think it would make a significant difference?
>>
> My opinion: probably not. However, I just thought of another drawback 
> with using Joeq's interpreter, namely you wouldn't be able to debug it 
> with a standard Java debugger. The Brakes-like approach doesn't have 
> this limitation. In addition, since that approach simply modifies the 
> bytecode it would still be optimized by Hotspot and would still 
> outperform any scripting language. Torsten, what's the status of your 
> work on this?
>
> Chris
>
Slight correction: the current implementation of Brakes does indeed have 
this limitation - it discards debugging info during class file 
enhancement - that would have to be fixed to make it truly usable, in my 
opinion.

Chris