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? Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
