Markus Wanner writes:
> Eric Anderson wrote:
> > Assuming that the code for getting memory usage is derived from the
> > code I wrote a long time ago (output looks similar, so likely); I
> > expect that the memory consumption differences are just sampling
> > effects. It sampled every 1 secon
Hi,
Eric Anderson wrote:
> Assuming that the code for getting memory usage is derived from the
> code I wrote a long time ago (output looks similar, so likely); I
> expect that the memory consumption differences are just sampling
> effects. It sampled every 1 second or so, and so changes to runti
Hi,
Stephen Leake wrote:
> I need the profile info more than the total time; I want to find out
> which particular function in mtn is slow. Then I want to add a ticker
> output to it, so I will know it's not hung; then maybe speed it up
> somehow.
Guessing you are on Linux, that sounds more like
Zack Weinberg writes:
> On Mon, Sep 22, 2008 at 3:09 PM, Markus Wanner <[EMAIL PROTECTED]> wrote:
> > This leads me to think that the STL implementation doesn't provide an O(1)
> > implementation for size()... savings is avg memory consumption seems to
> > confirm this, no?
>
> Now that's ju
Markus Wanner <[EMAIL PROTECTED]> writes:
> Hi,
>
> Stephen Leake wrote:
>> I don't know how to interpret these numbers. What tool did you run to
>> generate them?
>
> It's the output of compare.py from the nvm.cbench branch, which takes
> CSV inputs from the pythonic benchmark suite.
Ok, thanks
Hi,
Stephen Leake wrote:
> I don't know how to interpret these numbers. What tool did you run to
> generate them?
It's the output of compare.py from the nvm.cbench branch, which takes
CSV inputs from the pythonic benchmark suite.
> I need to get some profile data on running mtn over NFS; someth
Hi,
Derek Scherger wrote:
> Even if size does have to traverse a list to count the elements one
> would expect that traversing an *empty* list should be reasonably quick.
Yeah, but it the list is large, traversing is rather expensive, compared
to aborting and returning false upon seeing the firs
Markus Wanner <[EMAIL PROTECTED]> writes:
>> annotate-a-ref.csv annotate-a-new.csv p
>> annotate-avg-resident-MiB 30.12 23.72 0.00
>> annotate-avg-size-MiB 125.68 119.28 0.00
>> annotate-max-resident-MiB
Even if size does have to traverse a list to count the elements one would
expect that traversing an *empty* list should be reasonably quick.
All the same, empty() does seem a bit easier on the eyes and if it wins on
performance too then what the heck.
Cheers,
Derek
On Mon, Sep 22, 2008 at 3:09 PM, Markus Wanner <[EMAIL PROTECTED]> wrote:
> This leads me to think that the STL implementation doesn't provide an O(1)
> implementation for size()... savings is avg memory consumption seems to
> confirm this, no?
Now that's just bloody weird. I can't think of any r
Hi,
Zack Weinberg wrote:
Sure, but C++98 requires size() to be O(1) for every container, so
there's really no excuse for a 4-15% performance difference.
Here are the results I got from this test run. It's a debian lenny
machine, comparing these revisions:
new: 805c482bc9bb80cd393be7d3ba01a
Hi,
Zack Weinberg wrote:
Sure, but C++98 requires size() to be O(1) for every container, so
there's really no excuse for a 4-15% performance difference.
Hm.. I didn't know that, thanks.
Very strange. I'm just re-running the annotate benchmarks...
Regards
Markus
__
On Mon, Sep 22, 2008 at 2:18 PM, Markus Wanner <[EMAIL PROTECTED]> wrote:
>> I'm honestly surprised .empty() and .size() == 0 don't generate
>> identical code, but hey. Thanks!
>
> For example for doubly linked lists, it's pretty simple to tell whether they
> are empty or not, but counting the num
Spooky.
On Mon, Sep 22, 2008 at 11:18:14PM +0200, Markus Wanner wrote:
> Hi,
>
> Zack Weinberg wrote:
>> I'm honestly surprised .empty() and .size() == 0 don't generate
>> identical code, but hey. Thanks!
>
> For example for doubly linked lists, it's pretty simple to tell whether
> they are emp
On Mon, Sep 22, 2008 at 02:14:25PM -0700, Zack Weinberg wrote:
> I'm honestly surprised .empty() and .size() == 0 don't generate
> identical code, but hey. Thanks!
Imagine a linked list implementation. Finding out whether the
pointer to the first element is NULL is simple, and enough to answer
w
Hi,
Zack Weinberg wrote:
I'm honestly surprised .empty() and .size() == 0 don't generate
identical code, but hey. Thanks!
For example for doubly linked lists, it's pretty simple to tell whether
they are empty or not, but counting the number of elements in the list
requires traversing the li
On Mon, Sep 22, 2008 at 1:26 PM, Markus Wanner <[EMAIL PROTECTED]> wrote:
> in rev 805c482bc9bb80cd393be7d3ba01a65377d91d9c I've replaced lots of
> .size() == 0 (and similar) calls with .empty(). For one thing, I personally
> find it clearer and easier to read. And it's considered good practice
> b
Hi,
in rev 805c482bc9bb80cd393be7d3ba01a65377d91d9c I've replaced lots of
.size() == 0 (and similar) calls with .empty(). For one thing, I
personally find it clearer and easier to read. And it's considered good
practice because the implementation for most STL containers is simpler
and faster.
18 matches
Mail list logo
