---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102723/#review7076
---
This review has been submitted with commit
85817e3070f2ea750fb1
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102723/#review6920
---
This review has been submitted with commit
0025316378a26152b866
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102723/#review6919
---
Ship it!
- Josef Weidendorfer
On Sept. 29, 2011, 6:25 p.m., J
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102723/
---
(Updated Sept. 29, 2011, 6:25 p.m.)
Review request for kdelibs.
Changes
On Wednesday 28 September 2011, Rolf Eike Beer wrote:
> What happens if inPos is -1? pos becomes 0 then. Then we iterate over the
> whole list just to do "if (... && pos != 0)" which will never be true. So for
> this case (inPos == -1) the whole function can be avoided at all as it will
> never
2011/9/28 Rolf Eike Beer :
> Am Mittwoch, 28. September 2011, 15:47:25 schrieb Josef Weidendorfer:
>> On Wednesday 28 September 2011, Jaime Torres Amate wrote:
>
>> > and the removal of a for loop (I'm checking it this has been this way
>> > since the beginning, or if fixing it makes other things f
Am Mittwoch, 28. September 2011, 15:47:25 schrieb Josef Weidendorfer:
> On Wednesday 28 September 2011, Jaime Torres Amate wrote:
> > and the removal of a for loop (I'm checking it this has been this way
> > since the beginning, or if fixing it makes other things faster) as Rolf
> > has pointed.
>
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102723/
---
(Updated Sept. 28, 2011, 5:14 p.m.)
Review request for kdelibs.
Changes
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102723/#review6887
---
Ship it!
You rock :)
I'm surprised that the compiler doesn't c
On Wednesday 28 September 2011, Jaime Torres Amate wrote:
>
> > On Sept. 28, 2011, 8:59 a.m., Josef Weidendorfer wrote:
> > > I would expect that the ->constEnd() method completely gets inlined with
> > > compiler optimization turned on. So are you sure your change
> > > improves anything for a r
> On Sept. 28, 2011, 8:59 a.m., Josef Weidendorfer wrote:
> > I would expect that the ->constEnd() method completely gets inlined with
> > compiler optimization turned on. So are you sure your change
> > improves anything for a release build? Anything performance related always
> > needs to be
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102723/#review6881
---
I would expect that the ->constEnd() method completely gets inli
Am Dienstag, 27. September 2011, 20:42:54 schrieb Jaime Torres Amate:
> before: 2984 calls to constBegin, 0,00%. 2960531 calls to constEnd, 2.33%
> after: 2921 calls to constBegin, 0,00%. 2921 calls to constEnd, 0.00%
>
> before: calcDiversity, 55.83% (debug enabled)
> after: calcDiversity, 14,4
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102723/
---
Review request for kdelibs.
Description
---
Using this way to build a
14 matches
Mail list logo
