You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@esme.apache.org by Vassil Dichev <vd...@apache.org> on 2009/11/28 14:36:15 UTC
Memory allocation and lazy vals
I found a weird thing today. Lazy vals don't act lazy under certain conditions.
For those who are not familiar with lazy values, they are values which:
- are calculated on demand
- are memoized so that the next invocation won't compute the same code again
You can find a nice article about behavior of lazy vals here:
http://blogs.tedneward.com/2009/03/29/Laziness+In+Scala.aspx
In ESME's case, lazy values are used to format a message into XML and
XHTML only once per instance (does that ring any bells?). What happens
in Message, though, is that digestedXHTML, toXml and originalXml,
which are all lazy, are executed again and again on each consecutive
call! I'm not sure why that is, but if I change the access of object
text to returning a hardcoded value, it works as expected, and gets
evaluated only once.
I'm currently trying to find the reason for this phenomenon and find
workarounds. This detail undermines our implementation of caching
messages, but at least now we know what causes the strange behavior
observed by Markus.
Re: Memory allocation and lazy vals
Posted by Vassil Dichev <vd...@apache.org>.
> I hope I will have some time to do this tonight.
Markus, did I say thanks? Well, thank you also for pointing out my
obvious bug with messages loaded from DB and rendered again and again.
Re: Memory allocation and lazy vals
Posted by Markus Kohler <ma...@gmail.com>.
Sure,
I hope I will have some time to do this tonight.
Regards,
Markus
"The best way to predict the future is to invent it" -- Alan Kay
On Sat, Nov 28, 2009 at 4:46 PM, Richard Hirsch <hi...@gmail.com>wrote:
> @Markus: Can you please kick the tires on the "new" / "old" ESME?
> Let's see what a repaired ESME can do.
>
> :->
>
> D.
>
> On Sat, Nov 28, 2009 at 4:42 PM, Vassil Dichev <vd...@apache.org> wrote:
> > If it sounds stupid, then it probably is. Lazy vals work fine. One
> > thing to have in mind is that a lazy val is null, it will be
> > reevaluated again (the first thing that tripped me).
> >
> > The problem is that I relied on findMessages working correctly. It
> > didn't. Unfortunately the changes from access pools made it to always
> > hit the DB and not try the cache. I've fixed it now. (tests, tests,
> > tests)
> >
> > As a result, ESME is now as fast as we remember it from the beginning.
> >
>
Re: Memory allocation and lazy vals
Posted by Richard Hirsch <hi...@gmail.com>.
@Markus: Can you please kick the tires on the "new" / "old" ESME?
Let's see what a repaired ESME can do.
:->
D.
On Sat, Nov 28, 2009 at 4:42 PM, Vassil Dichev <vd...@apache.org> wrote:
> If it sounds stupid, then it probably is. Lazy vals work fine. One
> thing to have in mind is that a lazy val is null, it will be
> reevaluated again (the first thing that tripped me).
>
> The problem is that I relied on findMessages working correctly. It
> didn't. Unfortunately the changes from access pools made it to always
> hit the DB and not try the cache. I've fixed it now. (tests, tests,
> tests)
>
> As a result, ESME is now as fast as we remember it from the beginning.
>
Re: Memory allocation and lazy vals
Posted by Vassil Dichev <vd...@apache.org>.
If it sounds stupid, then it probably is. Lazy vals work fine. One
thing to have in mind is that a lazy val is null, it will be
reevaluated again (the first thing that tripped me).
The problem is that I relied on findMessages working correctly. It
didn't. Unfortunately the changes from access pools made it to always
hit the DB and not try the cache. I've fixed it now. (tests, tests,
tests)
As a result, ESME is now as fast as we remember it from the beginning.
Re: Memory allocation and lazy vals
Posted by Richard Hirsch <hi...@gmail.com>.
Vassil just did a commit, so it could already be fixed.
I'd try it out. :->
D.
On Sat, Nov 28, 2009 at 4:37 PM, Markus Kohler <ma...@gmail.com> wrote:
> W00T!
> ESME will fly as soon as this is fixed!
> Markus
>
> On Nov 28, 2009 2:36 PM, "Vassil Dichev" <vd...@apache.org> wrote:
>
> I found a weird thing today. Lazy vals don't act lazy under certain
> conditions.
>
> For those who are not familiar with lazy values, they are values which:
> - are calculated on demand
> - are memoized so that the next invocation won't compute the same code again
>
> You can find a nice article about behavior of lazy vals here:
> http://blogs.tedneward.com/2009/03/29/Laziness+In+Scala.aspx
>
> In ESME's case, lazy values are used to format a message into XML and
> XHTML only once per instance (does that ring any bells?). What happens
> in Message, though, is that digestedXHTML, toXml and originalXml,
> which are all lazy, are executed again and again on each consecutive
> call! I'm not sure why that is, but if I change the access of object
> text to returning a hardcoded value, it works as expected, and gets
> evaluated only once.
>
> I'm currently trying to find the reason for this phenomenon and find
> workarounds. This detail undermines our implementation of caching
> messages, but at least now we know what causes the strange behavior
> observed by Markus.
>
Re: Memory allocation and lazy vals
Posted by Markus Kohler <ma...@gmail.com>.
W00T!
ESME will fly as soon as this is fixed!
Markus
On Nov 28, 2009 2:36 PM, "Vassil Dichev" <vd...@apache.org> wrote:
I found a weird thing today. Lazy vals don't act lazy under certain
conditions.
For those who are not familiar with lazy values, they are values which:
- are calculated on demand
- are memoized so that the next invocation won't compute the same code again
You can find a nice article about behavior of lazy vals here:
http://blogs.tedneward.com/2009/03/29/Laziness+In+Scala.aspx
In ESME's case, lazy values are used to format a message into XML and
XHTML only once per instance (does that ring any bells?). What happens
in Message, though, is that digestedXHTML, toXml and originalXml,
which are all lazy, are executed again and again on each consecutive
call! I'm not sure why that is, but if I change the access of object
text to returning a hardcoded value, it works as expected, and gets
evaluated only once.
I'm currently trying to find the reason for this phenomenon and find
workarounds. This detail undermines our implementation of caching
messages, but at least now we know what causes the strange behavior
observed by Markus.