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

[Nicolas Desprès]

Hi Stephen,

Did you have any chance to look at the code? I would love to see it
integrated in the next release. That being said, there is no pressure.

Thanks,
-Nico

On Tue, Jul 16, 2013 at 1:40 PM, Nicolas Desprès
<nicolas.despres at gmail.com>wrote:

> 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
>



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