You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Anton Tagunov <at...@apache.org> on 2003/09/05 21:45:51 UTC
Re[2]: Configuration reporting
Hello, Berin!
BL> Also, while it is trivial to append strings, pulling the string back
BL> isn't so easy.
BL> For instance:
BL> <root>
BL> <component>
BL> <item>
BL> <element/>
BL> </item>
BL> <item>
BL> <element/>
BL> <item>
BL> </component>
BL> </root>
BL> We can trivially add to the path up until we reach the first close tag.
BL> At that time we have to rip off the current element's portion of the path.
BL> While the logistics can be solved with using a stack, I would like to
BL> avoid over-engineering this.
Just of academical interest: there may some easier ways then using
Stack, for instance a StringBuffer could be used.
Flavour 1:
when you need to rip off a path element and you know the length of the
name of the element that has just been closed, you just shorten the sb
by this length plus 1 (for the separator)
Flavour 2:
when you need to rip off a path element you just go searching the sb
from back to the begging untill you find the next separator (the '/'
char) and shorten the sb by that amount.
With a StringBuffer the amount of memory used will be way less then
for a Stack (in fact it will depend on the depth of the xml tree and
the lenghes of element names).
- Anton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re[3]: Configuration reporting
Posted by Anton Tagunov <at...@mail.cnt.ru>.
Hello Berin and All!
AT> Just of academical interest: there may some easier ways then using
AT> Stack, for instance a StringBuffer could be used.
<snip/>
AT> With a StringBuffer the amount of memory used will be way less then
AT> for a Stack (in fact it will depend on the depth of the xml tree and
AT> the lenghes of element names).
On the second thought, well, if we package the path with every
configuration element, then really the buffer for our StringBuffer
we be reallocated each time. So in fact this probably will save
NO memory at all. If on the other hand the Stack uses an
String[] array of a proper length under the hood, then using a Stack
will really waste almost no memory, the array will just be filled
with element names (and element names are String that have been
allocated already anyway).
So the real wast of memory here is not maintaining the Stack but
keeping the path information for every element in the Configuration.
So,
1) at the second glance Stack does not look a waste of memory
2) if we're worried about memory (and there may be good benefits
in ultimately pushing Avalon on Java2ME) then we probably could
think about constructing this info at runtime?
Although the current Configuration has no analog of
org.w3c.dom.Node.getParentNode(), it is theoretically
possible to add parent information to Configuration
and then the virtual path could be constructed only on
demand, when there really is an error, not for every node
3) going along these lines it might be also pretty usefull to
keep the filename as a separate string (allocated only once)
and the line and column number as integers and pack this all
into a single location string only on demand - when an error
has happpend, not for every configuration node
Cheers, Anton
P.S. Stephen, you have recently reported that Merlin footprint
is around 2Mb, I wonder how much of this could be saved this way?
Well, probably little, but for J2ME, and keeping in mind that
Configuration is framework, not even a container..
P.P.S. Noel and other administrators, sorry for the mess!
Will try to never post from unsubscribed addresses again,
it was my error!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Configuration reporting
Posted by Berin Loritsch <bl...@apache.org>.
Anton Tagunov wrote:
> Hello, Berin!
Hello!
> Just of academical interest: there may some easier ways then using
> Stack, for instance a StringBuffer could be used.
>
> Flavour 1:
>
> when you need to rip off a path element and you know the length of the
> name of the element that has just been closed, you just shorten the sb
> by this length plus 1 (for the separator)
>
> Flavour 2:
>
> when you need to rip off a path element you just go searching the sb
> from back to the begging untill you find the next separator (the '/'
> char) and shorten the sb by that amount.
>
> With a StringBuffer the amount of memory used will be way less then
> for a Stack (in fact it will depend on the depth of the xml tree and
> the lenghes of element names).
The other issue has to do with dynamically creating the configuration
objects.
For example, if I am creating a tree, I have to create the leaves before
the parent. Since there is no parent created yet, I can only put a guestimated
location path. For example:
DefaultConfiguration leaf = new DefaultCOnfiguration("name","/root/name");
DefaultConfiguration root = new DefaultConfiguration("root","/root");
root.addChild(leaf);
Now what happens when I call the method that creates this configuration
tree, and then add it to another configuration tree?
DefaultConfiguration realRoot = new DefaultConfiguration("problem","/problem");
realRoot.addChild(getConfigFromAbove());
When you look at the path for each element, and traverse the tree, then you
will see something like this:
/problem
/root
/root/name
(indents provided to show the logical relationship).
The path is more troublesome than it is worth unless it is always created
by the DocumentBuilder.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Configuration reporting
Posted by Stephen McConnell <mc...@apache.org>.
Anton Tagunov wrote:
>3) going along these lines it might be also pretty usefull to
> keep the filename as a separate string (allocated only once)
> and the line and column number as integers and pack this all
> into a single location string only on demand - when an error
> has happpend, not for every configuration node
>
+1
--
Stephen J. McConnell
mailto:mcconnell@apache.org
Sent via James running under Merlin as an NT service.
http://avalon.apache.org/sandbox/merlin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re[3]: Configuration reporting
Posted by Anton Tagunov <at...@apache.org>.
Hello Berin and All!
AT> Just of academical interest: there may some easier ways then using
AT> Stack, for instance a StringBuffer could be used.
<snip/>
AT> With a StringBuffer the amount of memory used will be way less then
AT> for a Stack (in fact it will depend on the depth of the xml tree and
AT> the lenghes of element names).
On the second thought, well, if we package the path with every
configuration element, then really the buffer for our StringBuffer
we be reallocated each time. So in fact this probably will save
NO memory at all. If on the other hand the Stack uses an
String[] array of a proper length under the hood, then using a Stack
will really waste almost no memory, the array will just be filled
with element names (and element names are String that have been
allocated already anyway).
So the real wast of memory here is not maintaining the Stack but
keeping the path information for every element in the Configuration.
So,
1) at the second glance Stack does not look a waste of memory
2) if we're worried about memory (and there may be good benefits
in ultimately pushing Avalon on Java2ME) then we probably could
think about constructing this info at runtime?
Although the current Configuration has no analog of
org.w3c.dom.Node.getParentNode(), it is theoretically
possible to add parent information to Configuration
and then the virtual path could be constructed only on
demand, when there really is an error, not for every node
3) going along these lines it might be also pretty usefull to
keep the filename as a separate string (allocated only once)
and the line and column number as integers and pack this all
into a single location string only on demand - when an error
has happpend, not for every configuration node
Cheers, Anton
P.S. Stephen, you have recently reported that Merlin footprint
is around 2Mb, I wonder how much of this could be saved this way?
Well, probably little, but for J2ME, and keeping in mind that
Configuration is framework, not even a container..
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org