On 09.04.2014 02:00, Stephen Kelly wrote:
My new optimizations make the VTK time comparable with before-refactor
on my machine.
The cmake run for my project seems to be at least as fast as it was
before too :)
Thanks!
Nils
--
Powered by www.kitware.com
Please keep messages on-topic and
On Sat, Apr 05, 2014 at 13:58:37 +0200, Stephen Kelly wrote:
I also looked at your local-speed-lang topic.
testing/merge is the most recent. I really need to clean up the branch
mess I've made (caused by attempting to merge two sets of work sessions
between work and home without nuking
On 04/05/2014 07:08 AM, Stephen Kelly wrote:
I agree of course that the performance is master currently is not
acceptable.
Re-cmake with v2.8.12.2:
$ time cmake ..
real0m0.712s
user0m0.692s
sys 0m0.020s
[snip]
Re-cmake with optimize-source-file-processing:
$ time cmake
Brad King wrote:
Do you have timings for running CMake on KDE?
With kdelibs branch KDE/4.13:
adb96ae67e2ae5d8ab543fc60f11750a42ed0c41
(after latest optimization)
real0m17.862s
user0m16.817s
sys 0m1.001s
9b1abc543e9aee946e093229e1715c4b8a961514
(after previous optimization)
real
Brad King wrote:
On 04/04/2014 11:57 AM, Stephen Kelly wrote:
I've pushed another commit which gets the time for the 2000 file testcase
from about 20s to about 4s for both Ninja and Makefiles. It fails a few
unit tests though and I don't have time right now to find out why. 4s is
still a bit
Ben Boeckel wrote:
On Fri, Apr 04, 2014 at 15:04:50 -0400, Ben Boeckel wrote:
What can be merged with those branches?
Looking at your branch closer, they look to be somewhat orthoganal, but
there may be conflicts laying around.
Yes, that's my conclusion too.
I also looked at your
On 04/04/14 12:45, Nils Gladitz wrote:
CMake execution time of one of my projects jumps from 0m6.121s
(2.8.12.2) to 1m5.084s (3.0.20140404-gce0aa).
Most time seems to be spend after -- Configuring done.
Any ideas?
Nils
Maybe this http://public.kitware.com/Bug/view.php?id=14758 has
On 04/04/2014 06:45 AM, Nils Gladitz wrote:
CMake execution time of one of my projects jumps from 0m6.121s
(2.8.12.2) to 1m5.084s (3.0.20140404-gce0aa).
Most time seems to be spend after -- Configuring done.
Please git bisect the problem.
Thanks,
-Brad
--
Powered by www.kitware.com
On 04/04/2014 02:51 PM, Brad King wrote:
On 04/04/2014 06:45 AM, Nils Gladitz wrote:
CMake execution time of one of my projects jumps from 0m6.121s
(2.8.12.2) to 1m5.084s (3.0.20140404-gce0aa).
Most time seems to be spend after -- Configuring done.
Please git bisect the problem.
Thanks, I
Nils Gladitz wrote:
Stephen is already looking into it.
Problem seems to show with large numbers of source files e.g.:
The Ninja generator was much slower than the Makefiles generator. I pushed
the optimize-source-file-processing topic with a commit which should fix the
major problem with
On 04.04.2014 17:35, Brad King wrote:
On 04/04/2014 11:13 AM, Stephen Kelly wrote:
The Ninja generator was much slower than the Makefiles generator. I pushed
the optimize-source-file-processing topic with a commit which should fix the
major problem with Ninja. I'll see if there is more
Brad King wrote:
On 04/04/2014 11:13 AM, Stephen Kelly wrote:
The Ninja generator was much slower than the Makefiles generator. I
pushed the optimize-source-file-processing topic with a commit which
should fix the major problem with Ninja. I'll see if there is more
opportunity for
On 04/04/2014 11:57 AM, Stephen Kelly wrote:
I've pushed another commit which gets the time for the 2000 file testcase
from about 20s to about 4s for both Ninja and Makefiles. It fails a few unit
tests though and I don't have time right now to find out why. 4s is still a
bit much, so
On Fri, Apr 04, 2014 at 17:13:12 +0200, Stephen Kelly wrote:
The Ninja generator was much slower than the Makefiles generator. I pushed
the optimize-source-file-processing topic with a commit which should fix the
major problem with Ninja. I'll see if there is more opportunity for
On Fri, Apr 04, 2014 at 15:04:50 -0400, Ben Boeckel wrote:
What can be merged with those branches?
Looking at your branch closer, they look to be somewhat orthoganal, but
there may be conflicts laying around.
For anyone with *large* Ninja files, this branch may be worth a try as
well:
15 matches
Mail list logo