The proposal to merge lp:~zorba-coders/zorba/feature-mem_size into lp:zorba has
been updated.
Status: Approved => Merged
For more details, see:
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_size/+merge/114764
--
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_size/+m
Validation queue job feature-mem_size-2013-02-08T23-51-38.613Z is finished. The
final status was:
All tests succeeded!
--
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_size/+merge/114764
Your team Zorba Coders is subscribed to branch lp:zorba.
--
Mailing list: https://launchpad.ne
FYI: I had to remove the XQuery test for an item's size because the expected
results can't be hard-coded since they're platform-dependent. For example, I
get totally different values on Mac OS X. The reason the C++ unit tests for
mem_sizeof() work (are platform-independent) is because the expe
Validation queue starting for merge proposal.
Log at:
http://zorbatest.lambda.nu:8080/remotequeue/feature-mem_size-2013-02-08T23-51-38.613Z/log.html
--
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_size/+merge/114764
Your team Zorba Coders is subscribed to branch lp:zorba.
--
Maili
The proposal to merge lp:~zorba-coders/zorba/feature-mem_size into lp:zorba has
been updated.
Status: Needs review => Approved
For more details, see:
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_size/+merge/114764
--
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_s
The proposal to merge lp:~zorba-coders/zorba/feature-mem_size into lp:zorba has
been updated.
Status: Approved => Needs review
For more details, see:
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_size/+merge/114764
--
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_s
The attempt to merge lp:~zorba-coders/zorba/feature-mem_size into lp:zorba
failed. Below is the output from the failed tests.
CMake Error at /home/ceej/zo/testing/zorbatest/tester/TarmacLander.cmake:275
(message):
Validation queue job feature-mem_size-2013-02-08T20-33-54.456Z is finished.
T
Validation queue starting for merge proposal.
Log at:
http://zorbatest.lambda.nu:8080/remotequeue/feature-mem_size-2013-02-08T20-33-54.456Z/log.html
--
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_size/+merge/114764
Your team Zorba Coders is subscribed to branch lp:zorba.
--
Maili
The proposal to merge lp:~zorba-coders/zorba/feature-mem_size into lp:zorba has
been updated.
Status: Needs review => Approved
For more details, see:
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_size/+merge/114764
--
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_s
Review: Approve
--
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_size/+merge/114764
Your team Zorba Coders is subscribed to branch lp:zorba.
--
Mailing list: https://launchpad.net/~zorba-coders
Post to : zorba-coders@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zor
Markos: can you approve this now?
--
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_size/+merge/114764
Your team Zorba Coders is subscribed to branch lp:zorba.
--
Mailing list: https://launchpad.net/~zorba-coders
Post to : zorba-coders@lists.launchpad.net
Unsubscribe : https://la
Review: Approve
--
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_size/+merge/114764
Your team Zorba Coders is subscribed to branch lp:zorba.
--
Mailing list: https://launchpad.net/~zorba-coders
Post to : zorba-coders@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zor
I think everything works now.
--
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_size/+merge/114764
Your team Zorba Coders is subscribed to branch lp:zorba.
--
Mailing list: https://launchpad.net/~zorba-coders
Post to : zorba-coders@lists.launchpad.net
Unsubscribe : https://launch
On Jan 10, 2013, at 1:56 PM, Markos Zaharioudakis wrote:
> Here is the 1st problem: inside mem_sizeof(const XmlNode& t), sizeof(T) (or
> sizeof(t)) should return 52 if t is actually an ElementNode. Of course, this
> is not possible since sizeof(T) is computed statically (i.e., at compile
> tim
On Jan 10, 2013, at 2:28 PM, Markos Zaharioudakis wrote:
>> The problem is infinite recursion. If I ask for the size of a tree, it's the
>> sum of all the nodes. If the root node includes the size of the tree, then
>> it
>> will recurse infinitely.
>
> I don't understand the infinite recursio
>>> The function alloc_sizeof( rstring const &s ) does not count the
>> book-keeping overhead for the various kinds of strings. For example, the
>> default rep (which is used for zstrings) adds 12 bytes oberhead (on 32-bit
>> machines).
>>
>> I changed it to:
>>
>>return s.capacity() + (s
>
> > The function alloc_sizeof( rstring const &s ) does not count the
> book-keeping overhead for the various kinds of strings. For example, the
> default rep (which is used for zstrings) adds 12 bytes oberhead (on 32-bit
> machines).
>
> I changed it to:
>
> return s.capacity() + (s.is
> On Dec 16, 2012, at 8:43 PM, Markos Zaharioudakis wrote:
>
> > The memory size of some std containers is underestimated, because the book-
> keeping overhead is not taken into account. I understand we cannot be 100%
> exact here, but should we try to consider some common std implementations and
>
> > The size of XmlTree is not counted.
>
> Right: because it's shared by all nodes in the tree.
>
> > An instance of XmlTree is shared by all nodex in the same xml tree. Maybe
> the size of the XmlTree should be attribute only to the root node of the tree.
>
>
> The problem is infinite rec
> On Dec 17, 2012, at 2:44 AM, Markos Zaharioudakis wrote:
>
> > size:size(foo) returns 101. This is wrong because just
> sizeof(ElementNode) is 52 and the tree foo consists of 2 element
> nodes, one text node and one (hidden) attribute node.
> >
> > The reason for this wrong result is in this st
On Dec 17, 2012, at 2:44 AM, Markos Zaharioudakis wrote:
> size:size(foo) returns 101. This is wrong because just
> sizeof(ElementNode) is 52 and the tree foo consists of 2
> element nodes, one text node and one (hidden) attribute node.
>
> The reason for this wrong result is in this struct:
On Dec 16, 2012, at 8:43 PM, Markos Zaharioudakis wrote:
> The memory size of some std containers is underestimated, because the
> book-keeping overhead is not taken into account. I understand we cannot be
> 100% exact here, but should we try to consider some common std
> implementations and m
The size of XmlTree is not counted. An instance of XmlTree is shared by all
nodex in the same xml tree. Maybe the size of the XmlTree should be attribute
only to the root node of the tree.
--
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_size/+merge/114764
Your team Zorba Coders is
size:size(foo) returns 101. This is wrong because just
sizeof(ElementNode) is 52 and the tree foo consists of 2 element
nodes, one text node and one (hidden) attribute node.
The reason for this wrong result is in this struct:
template
struct size_traits {
static size_t alloc_sizeof( T *p ) {
I added code to count the size of namespace bindings for element nodes.
--
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_size/+merge/114764
Your team Zorba Coders is subscribed to branch lp:zorba.
--
Mailing list: https://launchpad.net/~zorba-coders
Post to : zorba-coders@lists.
Review: Needs Fixing
--
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_size/+merge/114764
Your team Zorba Coders is subscribed to branch lp:zorba.
--
Mailing list: https://launchpad.net/~zorba-coders
Post to : zorba-coders@lists.launchpad.net
Unsubscribe : https://launchpad.net
The function alloc_sizeof( rstring const &s ) does not count the
book-keeping overhead for the various kinds of strings. For example, the
default rep (which is used for zstrings) adds 12 bytes oberhead (on 32-bit
machines). Also, I think the null-terminating byte is not counted.
--
https://code
My preference would be to make the default alloc_size() function raise an
error, instead of returning 0. Then, every class whose mem size may need to be
counted should have its own alloc_size() method, even if it does not have any
heap-allocated memory. I know this would be more "intrusive", but
I think we should define Base16::alloc_size() and Base64::alloc_size() methods.
The Base16::alloc_size() method should then be used in
HexBinaryItem::alloc_size() (which is not quite correct right now).
StructuralAnyUriItem::alloc_size() does not count theEncodedValue
StreamableStringItem::allo
The memory size of some std containers is underestimated, because the
book-keeping overhead is not taken into account. I understand we cannot be 100%
exact here, but should we try to consider some common std implementations and
measure the mem size accordingly? For example, std::map is typically
> I did some testing and the numbers are much better/consistent.
But I didn't change anything.
> It's at test/rbkt/Queries/zorba/item/size.xq.
This is impossible to test for since things like sizeof(N) (where N is some
native type like "int") and sizeof(S) (where S is some struct/class type)
v
Review: Needs Fixing
I did some testing and the numbers are much better/consistent.
I have started a test to make sure we keep this on the radar and understand if
something regresses.
It's at test/rbkt/Queries/zorba/item/size.xq.
Paul, could you please extend this test with at least one example f
> Why does ztd::alloc_sizeof( theKeys ) in src/store/naive/json_items.cpp:245
> return 0?
Because a specialization for HashMap wasn't ever defined. I really wish we'd
get away from using our own non-standard hashmaps. There really is no point.
--
https://code.launchpad.net/~zorba-coders/zorba/f
Review: Needs Information
Why does ztd::alloc_sizeof( theKeys ) in src/store/naive/json_items.cpp:245
return 0?
This doesn't seem to be true.
--
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_size/+merge/114764
Your team Zorba Coders is subscribed to branch lp:zorba.
--
Mailing li
I added Item::mem_size().
--
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_size/+merge/114764
Your team Zorba Coders is subscribed to branch lp:zorba.
--
Mailing list: https://launchpad.net/~zorba-coders
Post to : zorba-coders@lists.launchpad.net
Unsubscribe : https://launchpad.
> > Can we find a way to expose the functionality in the public C++ api?
>
> There are two choices:
>
> 1. Expose the entire mem_sizeof.h header and add:
>
> size_t alloc_size() const;
>
> on the public Item.
>
> 2. Add:
>
> size_t mem_size() const;
>
> on the public Item that simply
> Can we find a way to expose the functionality in the public C++ api?
There are two choices:
1. Expose the entire mem_sizeof.h header and add:
size_t alloc_size() const;
on the public Item.
2. Add:
size_t mem_size() const;
on the public Item that simply calls ztd::mem_sizeof() on th
Review: Needs Information
Can we find a way to expose the functionality in the public C++ api?
--
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_size/+merge/114764
Your team Zorba Coders is subscribed to branch lp:zorba.
--
Mailing list: https://launchpad.net/~zorba-coders
Post to
Please note the distinction between alloc_sizeof() and mem_sizeof(). The
former obtains the *additionally* dynamically allocated memory for an object of
type T. An 'int' has no additional memory beyond the size of the 'int' itself,
so the result of 0 is correct.
Why do you want to expose *onl
Review: Needs Fixing
I have added a new XQuery module (http://www.zorba-xquery.com/modules/item)
which currently provides one function x:allocated-size. The function invokes
Item::alloc_size.
Review comments
- The function Item::alloc_size should be exposed in the external C++ api.
- The funct
The proposal to merge lp:~zorba-coders/zorba/feature-mem_size into lp:zorba has
been updated.
Status: Approved => Needs review
For more details, see:
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_size/+merge/114764
--
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_s
Voting does not meet specified criteria. Required: Approve > 1, Disapprove < 1,
Needs Fixing < 1, Pending < 1. Got: 1 Approve.
--
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_size/+merge/114764
Your team Zorba Coders is subscribed to branch lp:zorba.
--
Mailing list: https://launc
Validation queue job feature-mem_size-2012-07-13T01-17-04.607Z is finished. The
final status was:
All tests succeeded!
--
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_size/+merge/114764
Your team Zorba Coders is subscribed to branch lp:zorba.
--
Mailing list: https://launchpad.ne
Validation queue starting for merge proposal.
Log at:
http://zorbatest.lambda.nu:8080/remotequeue/feature-mem_size-2012-07-13T01-17-04.607Z/log.html
--
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_size/+merge/114764
Your team Zorba Coders is subscribed to branch lp:zorba.
--
Maili
The proposal to merge lp:~zorba-coders/zorba/feature-mem_size into lp:zorba has
been updated.
Status: Needs review => Approved
For more details, see:
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_size/+merge/114764
--
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_s
Review: Approve
--
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_size/+merge/114764
Your team Zorba Coders is subscribed to branch lp:zorba.
--
Mailing list: https://launchpad.net/~zorba-coders
Post to : zorba-coders@lists.launchpad.net
Unsubscribe : https://launchpad.net/~zor
Paul J. Lucas has proposed merging lp:~zorba-coders/zorba/feature-mem_size into
lp:zorba.
Requested reviews:
Paul J. Lucas (paul-lucas)
For more details, see:
https://code.launchpad.net/~zorba-coders/zorba/feature-mem_size/+merge/114764
Added framework for calculating the total memory used by
47 matches
Mail list logo
