headers
Nick Fortescue | 2 Oct 2002 13:43

Memory performance inefficiency caused by Interpreter.DEBUG


I just submitted this to the bug database, but as performance issues had
been raised on the list I thought others might be interested in this
problem and solution.

A number of places in the beanshell code there are lines like:

		Interpreter.debug("Trying to load class: "+name);

This doesn't print anything is the default release, but StringBuffer
operations get used and memory gets allocated anyway to construct the
message strings (this doesn't matter so much with constant strings).
This can increase the frequency of garbage collections. There are two
bad offenders in ClassManagerImpl and NameSpace which get called a lot,
according the allocation profiling I've done with JProbe.

These are such an issue that in our local copy of the source I'm
wrapping these two in 

if(Interpreter.DEBUG) {
}

statements. This might help some of you if you are having memory use
issues. What the code could really do with is an audit for these. I've
used IDEA to check how often Interpreter.debug() is called and it finds
44 invocations. I can look which of these construct strings with the +
operator, and wrap them in if statements like the above, and submit a
patch if this would be useful Pat.

Nick
(Continue reading)

Permalink | Reply | 2 comments |
headers
Pat | 3 Oct 2002 23:39

Re: Memory performance inefficiency caused by Interpreter.DEBUG

On Wed, Oct 02, 2002 at 12:43:04PM +0100, Nick Fortescue wrote:
> 
> I just submitted this to the bug database, but as performance issues had
> been raised on the list I thought others might be interested in this
> problem and solution.
> 
> A number of places in the beanshell code there are lines like:
> 
> 		Interpreter.debug("Trying to load class: "+name);

Thanks for filing the bug report - that's the best way to keep track of these
things.  We do need to weed out these (hastily added) debug statements.  

I have just branched the code for 1.2 so that we can start applying bug fixes 
like these (and the many others people are waiting for) without waiting 
for 1.3. 

Thanks,
Pat

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 1 comment |
headers
Cengiz Gunay | 13 Oct 2002 02:39
Favicon

Patch to pass a namespace to desktop()


Hi,

I've proposed this approach some time ago, but I was reluctant to
implement it. My aim was to set a special initial namespace when the Swing
console appears. I used to use the ~/.bshrc file for doing this, but now I
needed more than that.

My patch allows doing the following from your application, being 100%
backwards compatible with the current source code (hopefully):

{
Interpreter bsh = new Interpreter();
bsh.eval("source(\"rc.bsh\"); desktop( this.namespace );");
}

In this way, the environment set in the rc.bsh file will be reflected in
the desktop.

Here's the diff from today's CVS version:

Index: src/bsh/commands/desktop.bsh
===================================================================
RCS file: /cvsroot/beanshell/BeanShell/src/bsh/commands/desktop.bsh,v
retrieving revision 1.9
diff -r1.9 desktop.bsh
11a12
> import bsh.NameSpace;
13a15,18
>       desktop( null );
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christopher Dillon | 21 Oct 2002 21:53
Favicon

About the "final" keyword...

Hi!

I was wondering if it was possible to have the "final" keyword
implemented...

It would obviously only have the scope of the current nameSpace but it
could prevent programmers that modify the code to do weird things (such
as changing the value ;D ) with some variables...

This may seem kind of weird, but I am working on a project were
BeanShell would fit pretty well, IF it had this functionnality...

If that seems not to be possible, is there a way to achieve the same
result?

Cheers
Chris

___________________________________________________________________
Haut Débit: Modem offert soit 150,92 euros remboursés sur le Pack eXtense de Wanadoo !
Profitez du Haut Débit à partir de 30 euros/mois : http://www.ifrance.com/_reloc/w

-------------------------------------------------------
This sf.net emial is sponsored by: Influence the future 
of  Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ad.doubleclick.net/clk;4699841;7576298;k?http://www.sun.com/javavote
Permalink | Reply | 1 comment |
headers
Pat | 25 Oct 2002 17:46

Re: About the "final" keyword...

On Mon, Oct 21, 2002 at 07:53:01PM +0000, Christopher Dillon wrote:
> 
> I was wondering if it was possible to have the "final" keyword
> implemented...
> 
> It would obviously only have the scope of the current nameSpace but it
> could prevent programmers that modify the code to do weird things (such
> as changing the value ;D ) with some variables...
> 
> This may seem kind of weird, but I am working on a project were
> BeanShell would fit pretty well, IF it had this functionnality...

It would be pretty easy to get this working... it was anticipated that we
would (on the list of things to do).

If you want to submit a bug report about (I'd consider it a bug, since the
keyword is there but it doesn't work) that would insure it doesn't
get missed in the future.

Thanks,
Pat

-------------------------------------------------------
This sf.net email is sponsored by: Influence the future 
of Java(TM) technology. Join the Java Community 
Process(SM) (JCP(SM)) program now. 
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0004en
Permalink | Reply | 0 comments |

Gmane