[cmake-developers] CMake is slow for project with hundred target and one command with large number of dependencies

[Nicolas Desprès]

Hi Stephen,

I have pushed more commits and now the problem is fixed and all the test
suite passes on my machine.

However it could even be faster. See my comment
in cmMakefile::Compare::operator():
https://github.com/nicolasdespres/CMake/blob/7c873c8f3e0b893b1a96d8097105aa79e0477651/Source/cmMakefile.cxx#L2023-L2036

What do you think?

Have a good day,
Nico




On Mon, Jul 15, 2013 at 5:33 PM, Nicolas Desprès
<nicolas.despres at gmail.com>wrote:

>
>
>
> On Mon, Jul 15, 2013 at 1:51 PM, Stephen Kelly <steveire at gmail.com> wrote:
>
>> Nicolas Desprès wrote:
>>
>> >> Yes that one or cmMakefile::GetSourceFileWithOutput(char const*). I can
>> >> send you a gzipped of my callgrind data off-list if you want (it
>> >> weights 534K).
>> >>
>> > If we had a map associating each input to output, we could maybe have
>> > better performance. WDYT?
>>
>> Perhaps. I can probably create the same callgrind data locally anyway,
>> but I
>> won't have a change until later to dig into this.
>>
>> On looking at the cmMakefile::GetSourceFileWithOutput code though, it
>> seems
>> that it might also be useful to maintain this->SourceFiles
>> and (*i)->GetCustomCommand()->GetOutputs() as sorted vectors. They are
>> rarely modified, so the O(1) -> O(log N) inserts probably won't matter
>> much,
>> but the O(N) -> O(log N) might provide a useful gain. Or, as most access
>> is
>> at generate time, keep the O(1) insertions, sort() after the configure
>> step,
>> and then use the binary search at generate time. Of course, I don't know
>> if
>> there are also configure-time accesses which would be difficult to isolate
>> from the generate-time ones.
>>
>> Does that make any sense?
>>
>
> I think so.
>
> I fixed my "timeout" problem for writing the test, and pushed a first
> draft of a commit fixing this issue.
>
> I have the remaining test failling:
>  56 - ExportImport (Failed)
>  87 - CustomCommand (Failed)
>
> I will investigate them tomorrow.
>
> --
> Nicolas Desprès
>



-- 
Nicolas Desprès
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20130716/ba7b9b1e/attachment.html>