Re: [abc] spec formalisms section

I've committed a new set of numbers to CVS. Please let me know if I've
run the wrong variations, though I'm pretty sure they're the ones you meant.

I wan't sure what exactly you wanted put in the memory column of the
table, I've entered the final memory consumption in each case.

I've also committed Figures/jigsaw-luinmeth.tar.gz, which is the actual
output of the benchmark runs. Each output file contains five columns;
the first is an iteration count, the second -- time elapsed since start
of run, the 5th -- memory usage at that point.

- P

Oege de Moor wrote:

>
> I've update Section 3.3, but not yet with Julian's new analysis
> for determinining whether negative bindings can be dispensed with -
> that needs to be worked into the first half.
>
> Regarding the second half of the section, in particular the
> LUInMeth benchmark:
>
> The *official* version is
>
> RedThisJPCflowLockTraceMatch.aj
>
> this is the tracematch number that should appear in Table 7. Accordingly
>
> ReducedLockAspect.aj
>
> is what should be used for the AspectJ column in this row.
>
> -----------------------------------------------------
>
> For Section 3.3, I'd like to have execution times and memory consumption
> over time for these four and no others:
>
> RedThisJPCflowLockTraceMatch.aj
> (as above)
> RedThisJPCflowLockTraceMatch.aj with thisJPIdentity
> (two versions, just take the best)
> ReducedLockTraceMatch.aj
> LockTraceMatch.aj
> (i.e. non-reduced)
>
>
> -----------------------------------------------------
> For the future work section, it would be nice to speculate
> on the possibility of automatically achieving the effect
> of using "contains", as described in Section 3.3.
>
>
>
Received on Mon Mar 13 22:15:39 2006