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

Nicolas Desprès nicolas.despres at gmail.com
Mon Jul 15 11:33:49 EDT 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20130715/ddb69cc1/attachment.html>


More information about the cmake-developers mailing list