[abc-users] Tracematches performance query

Hi,

I have been conducting a test to measure the performance of tracematches.
While tracematches ran slower(though not by a great deal), that was to
be expected, but what surprised me was the memory usage. I had a
hand-coded aspect which uses a Map to keep track of the Account objects.
The hand-coded aspect uses 18MB, while the tracematch took up 40MB. This
is measured via Task Manager (I'm running on Windows XP). Compiled
separately via ajc and abc with tm extension for the hand-coded aspect
and tracematch respectively.
The benchmark was based on the tracematch I queried a while back, which
is now a simplified version of a tracematch binding an Account object
calling 1 withdraw() followed by 1 deposit() call.
I was wondering why are tracematches taking up much more memory compared
against hand-coded aspects?

Code is as follows:

class Account {
    private double amount = 0.0;
    
    public Account(double amt) {
        this.amount = amt;
    }
    
    public void deposit(double value) {
        this.amount += value;
    }

    public void withdraw(double value) {
        this.amount -= value;
    }
}

Main test file
class Test {
    public static void main(String[] args) {
        Account[] accounts = new Account[100000];
       
        for(int i = 0; i < 100000; i++) {
            accounts[i] = new Account(1.0);
        }
        // Test running time
        long time;
        for(int i = 0; i < 10; i++) {
            time = System.currentTimeMillis();
           
            for(int j = 0; j < 100000; j++) {
                accounts[j].withdraw(1.0);
                accounts[j].deposit(1.0);
            }
           
            System.out.println("Operation took " +
(System.currentTimeMillis() - time) + " milliseconds");
        }
       
        //while(true) {}
    }
}

Tracematch:
public aspect AccountTM {
    tracematch (Account a) {
        sym wd after:
            call (* Account.withdraw(..)) && target(a);
        sym dp after:
            call (* Account.deposit(..)) && target(a);
        wd dp {
             //System.out.println("1 withdraw and 1 deposit method calls
made by " + a);
        }
    }
}

Hand-coded aspect:
import java.util.*;

public aspect TracematchAccount {
    private Map wdmap = new IdentityHashMap();
    private Map dpmap = new IdentityHashMap();
   
    // Condition to check for withdraw method calls
    after(Account a): call(* Account.withdraw(..)) && target(a) {
        if(!wdmap.containsKey(a)) {
            wdmap.put(a, "Account");
        }
       
        if(dpmap.containsKey(a)) {
            dpmap.remove(a);
        }
    }
   
    // Condition to check for deposit method calls
    after(Account a): call(* Account.deposit(..)) && target(a) {
        if(dpmap.containsKey(a)) {
            dpmap.put(a, "Account");
        }
       
        if(wdmap.containsKey(a) && dpmap.containsKey(a)) {
            //System.out.println("1 withdraw and 1 deposit method calls
made by " + a);
            wdmap.remove(a);
            dpmap.remove(a);
        }
    }
}

The reason why I asked was because I thought tracematches were designed
to be memory safe, therefore its memory consumption should be more or
less on par with the hand-coded aspect (as in the benchmarks shown on
the paper). Thus an opinion on this matter would be greatly appreciated.
Thanks.
Received on Wed Mar 19 2008 - 18:46:34 GMT