Re: [abc-users] Relational aspects running time

From: Alan Teoh <alan.teoh07_at_imperial.ac.uk>
Date: Sun, 16 Mar 2008 21:04:16 +0000

Hi Eric,
Perhaps my previous benchmark was a bit too small to be an indicator of
anything.

The following was the full code that I used. The relational aspect and
the Bit remain the same.

class Test {
    public static void main(String[] args) {
        Bit[] bits = new Bit[10000];
        Bit b1 = new Bit();
        Bit b2 = new Bit();
        for(int i = 0; i < 10000; i++) {
            bits[i] = new Bit();
        }
        // Test memory consumption
        for(int i = 0; i < 5000; i+=2) {
            Equality.associate(bits[i], bits[i+1]); // Problem seems to
start here
            System.out.println(i);
        }
       
        Equality.associate(b1, b2);
        // Test running time
        long time;
        for(int i = 0; i < 10; i++) {
            time = System.currentTimeMillis();
           
            for(int j = 0; j < 1000000; j++) {
                b1.set();
                b1.clear();
            }
           
            System.out.println("Operation took " +
(System.currentTimeMillis() - time) + " milliseconds");
        }
    }
}

I ran the same code with association aspects (using the aspect provided
by the paper by Sakurai et al.), and the benchmark was over in a few
seconds. However, with relational aspects, the computation seems to take
some time in the loop (for(int i = 0; i < 5000; i+=2) ). In fact,
memory(Java heap space) runs out when i = 8. And as in the previous
email, when I commented the relational advices off, the code will run
and finish quickly without such problems. Obviously, by doing
that(commenting the relational advices) I would have defeated the point
of relational aspects, so that was the reason why I was wondering what
could be wrong with it?

Thanks again.

Eric Bodden wrote:
> Hi, Alan.
>
> Your benchmark is way too small to conclude anything at all about running time.
>
> In general, as we write in the paper, relational aspects *are* slower
> than the implementation by Sakurai et al.. However, there should be no
> exponential increase.
>
> Eric
>
>
>
> On 16/03/2008, Alan Teoh <alan.teoh07_at_imperial.ac.uk> wrote:
>
>> Hello,
>>
>> I have been playing around with relational aspects, and I stumbled upon
>> a problem with its running time. Code is as follows (using Sakurai et
>> al's Bit idea from association aspects, as well as the relational aspect
>> from the relational aspects paper):
>>
>> class Bit {
>> boolean value = false;
>> public void set() { value = true; }
>> public void clear() { value = false; }
>> boolean get() { return value; }
>> }
>>
>> Relational aspect is as follows:
>>
>> relational aspect Equality(Bit b1, Bit b2) {
>> relational after(): call(public void Bit.set()) && target(b1) {
>> b2.set();
>> }
>> relational after(): call(public void Bit.clear()) && target(b1) {
>> b2.clear();
>> }
>> }
>>
>> Using this Test file:
>> class Test {
>> public static void main(String[] args) {
>> Bit[] Bits = new Bit[10000];
>> Bit b1 = new Bit();
>> Bit b2 = new Bit();
>> Bit b3 = new Bit();
>> Bit b4 = new Bit();
>> Bit b5 = new Bit();
>> Bit b6 = new Bit();
>> Bit b7 = new Bit();
>> Bit b8 = new Bit();
>> Bit b9 = new Bit();
>> Bit b10 = new Bit();
>> Equality.associate(b1, b2);
>> Equality.associate(b3, b4);
>> Equality.associate(b5, b6);
>> Equality.associate(b7, b8);
>> Equality.associate(b9, b10);
>> }
>> }
>>
>> My problem is that whenever I try to associate more and more Bit
>> objects, the running time just increases in an exponential manner. When
>> I comment the relational advices out however, the running time is quick,
>> thus the relational advices are causing the problem here. I realise that
>> for every relational advice is made up by a tracematch. However, I do
>> not see how it actually affects the running time in such a drastic
>> manner, given that the only amount of objects(which are visible to me)
>> that are involved here are only 10, and there are only 5 aspect
>> instances. Explanation on this matter would be greatly appreciated.
>>
>> Many thanks.
>>
>>
>>
>>
>>
>>
>
>
>
Received on Sun Mar 16 2008 - 21:04:24 GMT

This archive was generated by hypermail 2.2.0 : Sun Mar 16 2008 - 21:20:10 GMT