Howard M. Lewis Ship
2003-01-02 04:03:24 UTC
Is there a good, free (and/or open source) profiling tool?
Tapestry 2.4 performance may be slipping a little; I can't tell because I
don't have access to any profiling tools. Luis Neves has previously
commented that the bottleneck he observes is in character-to-byte
conversions, deep inside java.io. I'm now concerned that all the cool 2.4
features such as dynamic page and component discovery are also eating up too
many cycles (especially when a page is first loaded). Also, I'm getting
concerned about inneficient threading, since there are more chunks of
Tapestry that must be synchronized.
The new page persistance stuff is working well, though its a bit more picky
about what types of objects are allowed as persitent properties. Each
persistant page property is now stored individually in the HttpSession. The
engine now only stores a list of pages with persistent properties.
The basic types, such as String, Number, Boolean work fine. It
differentiates between mutable and immutable objects. Immutable objects are
String, Number, Boolean, java.util.Date (which is slightly fudging), Enum
and anything marked as IImmutable (a new marker interface for immutable
objects).
Mutable objects are tougher since the persistance wants to keep an isolated
copy of properties. That is, fireObservedChange() results in a copy being
made, and when a page is rolled back in a later request cycle, a copy (of
the copy) is made.
It's less efficient, but it means no surprises, especially in a clustered
environment. It forces the user to be careful about setting values, you
must follow a get/modify/set pattern, no fudging. It's also going to help
with some timing issues that occur when multiple requests against the same
engine run concurrently ... triggered by frames, but also by private assets.
The problem is handling the copying of values. At best, its going to do a
shallow copy. As a last resort, Serializable objects are serialized and
deserialzed (to make a deep copy).
Individual classes or interfaces need their own handler (IValueCopier)
registered with a IValuePersister. The good news is this provides a clean
way to handle things like EJBObject (which is now converted to an
EJBObjectWrapper, which implements Serializable to read and write the
object's handle).
However, for mutable objects like List, a specific handler must be created,
i.e.:
public class ListCopier implements IValueCopier
{
public Object makeCopyOfValue(Object value)
{
List list = (List)value;
return new ArrayList(list);
}
}
I think this is the right course to pursue, but I'm concerned that the
framework will get finicky.
Status: 22,440 NCLOC, 70.5% coverage
----
Howard Lewis Ship
hlship-***@public.gmane.org
http://tapestry.sf.net
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Tapestry 2.4 performance may be slipping a little; I can't tell because I
don't have access to any profiling tools. Luis Neves has previously
commented that the bottleneck he observes is in character-to-byte
conversions, deep inside java.io. I'm now concerned that all the cool 2.4
features such as dynamic page and component discovery are also eating up too
many cycles (especially when a page is first loaded). Also, I'm getting
concerned about inneficient threading, since there are more chunks of
Tapestry that must be synchronized.
The new page persistance stuff is working well, though its a bit more picky
about what types of objects are allowed as persitent properties. Each
persistant page property is now stored individually in the HttpSession. The
engine now only stores a list of pages with persistent properties.
The basic types, such as String, Number, Boolean work fine. It
differentiates between mutable and immutable objects. Immutable objects are
String, Number, Boolean, java.util.Date (which is slightly fudging), Enum
and anything marked as IImmutable (a new marker interface for immutable
objects).
Mutable objects are tougher since the persistance wants to keep an isolated
copy of properties. That is, fireObservedChange() results in a copy being
made, and when a page is rolled back in a later request cycle, a copy (of
the copy) is made.
It's less efficient, but it means no surprises, especially in a clustered
environment. It forces the user to be careful about setting values, you
must follow a get/modify/set pattern, no fudging. It's also going to help
with some timing issues that occur when multiple requests against the same
engine run concurrently ... triggered by frames, but also by private assets.
The problem is handling the copying of values. At best, its going to do a
shallow copy. As a last resort, Serializable objects are serialized and
deserialzed (to make a deep copy).
Individual classes or interfaces need their own handler (IValueCopier)
registered with a IValuePersister. The good news is this provides a clean
way to handle things like EJBObject (which is now converted to an
EJBObjectWrapper, which implements Serializable to read and write the
object's handle).
However, for mutable objects like List, a specific handler must be created,
i.e.:
public class ListCopier implements IValueCopier
{
public Object makeCopyOfValue(Object value)
{
List list = (List)value;
return new ArrayList(list);
}
}
I think this is the right course to pursue, but I'm concerned that the
framework will get finicky.
Status: 22,440 NCLOC, 70.5% coverage
----
Howard Lewis Ship
hlship-***@public.gmane.org
http://tapestry.sf.net
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf