Thanks Slava.
I thought for sure I saw BshClassManager in there, but I could totally be
mistaken.
Jim
At 11:38 AM 8/31/2001 +1000, Slava Pestov wrote:
>Hi,
>
>This bug is fixed in jEdit 3.2.1 by making the NameSpace class cache
>failed class name lookups.
>
>jEdit doesn't include BshClassManager and doesn't need to because it
>already has its own JAR class loader.
>
>Slava
>
>On Thu, Aug 30, 2001 at 08:33:47PM -0700, Jim wrote:
> > Well I wasn't imagining things. I traced the problem into beanshell,
> where
> > there was seemingly some un-optimized algorithms causing the problem. I
> > sent the following email to the beanshell dev list, and they replied
> > stating that it shouldn't be happening. I traced further, and found that
> > jEdit is omitting a critical part of beanshell - the bsh.classpath
> > subpackage. This includes, amongst other things, the class
> > ClassManagerImpl, which includes caching for package namespace
> > lookups. The beanshell stuff works fine without it - but definitely not
> > optimally.
> >
> > So I am wondering - is there a reason for this omission?
> >
> > The slowdown problem would arise for jEdit users if they have beanshell
> > actions that call packaged classes (ie com.mypackage.MyClass). If the
> > actions are not repeated the hit is not necessarily noticable, but if they
> > are then they can slow the program down drastically. Short of including
> > the proper beanshell classes, it can be worked around by using a beanshell
> > import in your actions, so you can then reference the classname without
> > qualification.
> >
> > Thanks, and sorry to keep bothering everyone. I do recognize that the
> > jEdit dev list is very busy now with more important problems, but I
> thought
> > I'd share what I found out in case anyone is interested.
> >
> > Jim
> >
> > -----------------------------------
> > Original message to beanshell dev list. Note the heuristic described is
> > not aappropriate given that there already exists appropriate cache
> > mechanisms, they just aren't in the jEdit distribution for whatever reason.
> > -----------------------------------
> >
> >
> > Hi,
> > I found the following performance problem while developing a jEdit plugin.
> > jEdit uses beanshell for defining actions. I found that packaged vs
> > nonpackaged classes behaved differently, wrt speed, namely. "Packaged"
> > names (ie com.abc.MyClass) are never *effectively* cached. The problem
> > seems to be the algorithm in
> > Name.consumeNextObjectField(...)/NameSpace.getClass(...) that checks for
> > classes.
> > I see that it goes through the dot-delimited name, searching for a class.
> > So, if I reference com.abc.MyClass, it checks all of the following for
> > being a class:
> > com
> > com.abc
> > com.abc.MyClass
> > Ok, so that seems reasonable - the first time. But after that, the name
> and
> > class are cached, right? Sort of. They are cached *if* a class is found
> > (naturally). But since the caching happens in NameSpace, and is called
> from
> > Name in the pieces above, it only caches com.abc.MyClass. NameSpace has no
> > idea that com and com.abc are associated with com.abc.MyClass, and of
> > course no classes are found for them, thus no caching ever happens.
> > Possible Solution
> > In the search in Name through the name components, reversing the order
> > solves this problem. In this case, it would try com.abc.MyClass, com.abc,
> > and com. Does this cause other problems is a question though? If the item
> > is a qualified field, such as com.abc.MyClass.someField, it would be
> better
> > than it is now, but if it were unqualified, like MyClass.someField, it
> > would be worse since it's checking to see if MyClass.someField is a class
> > each time. For apackage.MyClass.someField, it's a wash. So perhaps an
> > algorithm that counts parts is in order: if countParts(evalName) > 2, then
> > check for class in reverse order. If exactly two parts, it might never be
> > known if it's class first (MyClass.someField) or class second
> > (apackage.MyClass). But a better guess can be made by checking
> > capitalization, since often (only by convention true, but widely
> adopted it
> > seems) classes will be capitalized and fields/methods will have a lower
> > case first letter. So we can say "if first letter of last part is upper
> > case, then reverse search."
> > ...in Name.consumeNextObjectField(...):
> > /*
> > Keep adding parts until we have a class
> > */
> > Class clas = null;
> > String lastPart = evalName.substring(evalName.lastIndexOf('.') + 1);
> > int i, n = countParts(evalName);
> > char c = lastPart.charAt(0);
> > if (n > 1 && c >= 'A' && c <= 'Z') {
> > // Reverse search...
> > for(i = n; i >= 1; i--)
> > if ( (clas = namespace.getClass(prefix(evalName, i))) != null )
> > break;
> > } else {
> > for(i = 1; i <= n; i++)
> > if ( (clas = namespace.getClass(prefix(evalName, i))) != null )
> > break;
> > }
> >
> > Another possibility is in Name.getClass, if com, com.abc, etc are not
> > classes, then a "negative cache" could be used to store tokens that are
> > known not to be classes, thereby eliminating the costly Class.forName on
> > subsequent checks of "com" or "org" or whatever, etc.
> > Am I overlooking anything? I am new to beanshell so perhaps I've missed
> > something. But the above fix has solved the specific problem I described.
> > Thanks,
> > Jim
> >
> >
> >
> > --
> > -----------------------------------------------
> > jEdit Developers' List
> > jEdit-devel@...
> > http://lists.sourceforge.net/lists/listinfo/jedit-devel
>
>--
>-----------------------------------------------
>jEdit Developers' List
>jEdit-devel@...
>http://lists.sourceforge.net/lists/listinfo/jedit-devel
|
