Re: [abc] compile times

On Tue, 14 Dec 2004, Ondrej LHOTAK wrote:

> Second, I tried profiling it with hprof. Nothing obvious came up.
> However, as with many Java programs, a big chunk of the time is being
> spent in various places in the Java collections classes. From past
> experience, I know that these are very slow compared to low-level array
> operations. That got me wondering whether the Eclipse compiler also uses
> these slow standard collections, so I checked the CVS. It turns out that
> it doesn't use them at all, and it even uses OO features in general
> sparingly. Everything is done with arrays, and often, rather than use
> objects and virtual dispatch, it quite happily uses int constants and a
> switch statement, just like a typical C program. s/String/char[]/. As
> for BCEL, it does use the Java library a little bit, but it still uses
> arrays for the bulk of the stuff, and int constants rather than objects.

hm, a little aspect that picks out all the calls to collection classes
made directly from abc returns a significant number, but it's not huge.
Of course it's very possible that the significant calls are made from
deep within Polyglot and Soot, not from the abc code. Perhaps we
should compile both with an aspect that times all such calls.

> More generally, I find it quite odd that we're evaluating abc's
> *architecture* by comparing it to ajc, a system with a different
> architecture, but also very different components.

It is not true that ajc has a different architecture. In fact, it
is remarkably similar to abc. It also uses a separator to leverage
the existing Java compiler; it has a static weaver and advice
weaver in the same way as abc does.

The big difference between the two are the components, not the
overall structure. So that is what needs to be evaluated. The
components give better extensibility and optimisation, but at
what price?

> Since it is very
> much possible for the components themselves to have vastly different
> performance, if we only want to compare the architectures, shouldn't
> we keep the components constant?

I'm not sure what this means: see above, the point of our architecture
*are* the components.

> For example, rather than compare abc
> to ajc, we should be comparing abc to Polyglot/JavaToJimple/Soot.

Right, of course we should show comparisons between just compiling the
base program, and with the extra cost of weaving in an aspect.
And we could take ajc+(time to run soot) as another comparison
point.

But almost every reviewer of abc papers so far has mentioned compiletime
compared to ajc. We have to say something solid about it.

> Or
> do we consider the choice of components a part of the architecture?

yes, as said above.

> If so, then perhaps we should have decided that we care so much about
> compile-time performance before we started writing abc, benchmarked the
> components, and used Eclipse/BCEL rather than Polyglot/Soot.

Ondrej, please moderate your levels of irritation on email.

No one suggested that "we care so much about
compile-time performance". I read the reviews of the CC paper, and
concluded we needed a little section about it. The fact that the
results were worse than (at least I) expected sparked some discussion.
Aren't you the guy who on the way to Hursley was saying that
"abc is not slow"?

-O
Received on Wed Dec 15 11:52:08 2004