Milian Wolff wrote: >> I'm concerned that the memory usage of a daemon implementing the proposed >> capabilities may be too large to be practical (at least without a major >> redesign of certain structures that tend to duplicate substrings, or >> some kind of out-of-core approach). > > This sounds like optimizations to that daemon will benefit CMake.
FYI I merged a reduce-allocations branch to next for testing. It came from Milian here: https://github.com/steveire/CMake/pull/1 Milian also mentioned the possibility of using something like a sqlite database (probably what you meant by out-of-core above) for definitions for querying by the daemon. I also mentioned some possibile optimization possibilities, such as removing the closure of definitions created for all directories. I wrote a branch which does that some months ago, but it resulted in a slow down. I'll see if I can rebase the commit to master and push it to github, together with a patch for avoiding computing the hash multiple times in cmDefinitions. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
