Re: [Webmacro-devel] Help - the binary operator bug is weird

[Marc P. <ma...@an...>]

On Mon, 14 Jul 2003 13:26:50 -0400, Keats <ke...@ea...> wrote:

> [Hey all.  I'm just returning from vacation an trying to catch up.]
>
> I can look at this again.  I spent some time on this a while back, but I 
> was
> unable to create a simple test case that consistently reproduced the
> problem.  Now that we apparently have one, I'll poke at it a bit.

Pah! Apparently eh?! It's 100% verbatim man!

I was thinking about replacing all Vector usage with ArrayList in there 
which -should-give us some performance benefits because ArrayList is not 
synchronised, but I am wary of this now, because I am not sure how/if 
access to PropertyOperatorCache is synchronized - and that perhaps POC is 
taking advantage of Vector's synchro.

Keats - I can show you where the problem is in the code:

PropertyOperatorCache.java line 892:

        // if we're at the binary-settable parent, try direct first
        if (pos == binPos)
        {

            // try direct -- move to direct parent and try from there
            Object parent = null;
            try
            {
                parent = getProperty(context, instance, names, pos, pos);

The above line is the problem. For binary set (versus hash put) this line 
is broken. If you change the "end" parameter to "pos + 1" then binary set 
will work because getProperty will successfully find the property.

However if you do that, hash "put" breaks - watch the unit test TestGetSet 
to see it break if you put the +1 in, whereas TestBinaryAccessor will run 
fine with the "+1" in.

It's "well nasty".

For what it's worth I really think if we could come up with a better design 
for POC we would get some serious performance wins. Currently it often does 
lots of complex "get" operations when you do a binary "set" - just to see 
if the property exists.

I'm not sure all of these are needed, but I appreciate that the dynamic 
nature of property resolution means that a lot of the time this is 
required. However, most of the "set" code relies on exceptions not 
occurring, rather than the result of the "get"s which makes me think that 
we can get some performance wins here.

Also, binary "set" is slow according to the docs as it always expects and 
exception to occur, and then just swallows it.


Marc
-- 
Marc Palmer
Contract Java Consultant/Developer

* Available For Hire *

See my CV at  http://www.anyware.co.uk/marc/