[Nitro] Serious discussion on Annotaitons - Part II

transfire at gmail.com transfire at gmail.com
Sun Nov 12 15:21:53 EST 2006

George Moschovitis wrote:
> Hello Tom,
> I had a look at your new annotation implementation. The main
> thing that concerns me is how an annotation lookup relates to
> a plain hash lookup.

Cool. I'm glad you were able to have a look.

> In Nitro and Og we are mainly reading the
> annotation (the writes are very infrequent, typically on
> application startup). I am worried that the search in heritage
> on every read introduces a time penalty. Perhaps you should copy
> annotations from the heritage in the current class to avoid the
> 'deep' search the next time, something like a cache. You could
> set a dirty flag on annotation write and purge this annotation
> 'cache'.

Yea. There is a penalty here, though I would expect it not to be too
too bad -- the typical class has only three or four inheritance layers.
We could do as you suggest, but to ensure correct behavior would
require that when ever a classes annotation is changed all it's
subclass must also be scanned and updated if need be. I realize reading
is more common than writing, but this kind of writing overhead would
likely be orders of magnitude greater than the current read overhead.
So it might not actually be worth it. It might just be better for Og to
cache annotation reads, when possible, in areas of performance concern.

Of course I'll look at the code again and see if I can lower the read
overhead further.

There is one other possiblity however, while it still would incur some
penalty I expect it would be fairly lower. Instead of storing
annotations in a hash, we could store them in class methods. Eg.

  Bar.ann :foo, :class => Integer

could translate into

  def Bar.ann_foo
    super + @ann_foo

  @ann_foo += {:class => Integer}

where #+ is an alias for Hash#merge.

This essentially utilizes Ruby's internal inheritance features to do
the the same thing my implementation does manually. So although it's
doing the same thing, it should be fairly faster. It also means the
basic notation for annotation lookup is:


'ann :foo, :class' notatio would of course translate into this.

> I guess we should profile the current annotation lookup against
> a plain hash lookup. Perhaps the speed penalty is not much after
> all.

Hmm... I could put that together -- if you don't beat me to it first ;)

> About the global variable. I don't mind having global variables
> but why would we need to scan all annotations?

Not sure -- I at least consider every possibility I can think of.
Perhaps someone's using it for a micro test suite, or an aop thingy and
they need to scan them all before the rest of the main code exectues?
In any case it isn't a big deal obviously as there is a very good
chance of YAGNI. So the class instance variable is probably best.

> BTW, please notice that the code in 'ann' and 'ann!' is essentially
> the same, perhaps you could refactor this?

Yes, probably could, I just didn't see an easy way off hand w/o adding
another method which I wanted to avoid --just as I may get rid of
#heritage itself mergin it into #ann.

> In any case, thanks for your hard work. I really hope we can have
> the annotation issue resolved the coming week, so I can port Nitro
> to the new implementation.

Me. Too. Facets has come a long way since 1.4+ series (now going on
1.8+). And it's ready to take another big step too. So I want to get
Nitro/Og over to the latest and greatest before I start moving toward
teh coold new features of 2.0. (2.0 might just blow people's minds ;)


More information about the Nitro-general mailing list