[CMake] load_command not scriptable

[Tobias Becker]

Thanks for the Answer!
I actually do not want to alter CMake in any way (and I don't want to
create a custom cmake executable) if possible.  load_command would have
been perfekt.

I am losing alot of performance in my map_set() map_get() etc functions
which translate down to set_property(GLOBAL...) and get_property(GLOBAL)
I am further losing especially much performance when using my eval()
function which dynamically runs cmake code and on which alot of my lib is
based as it is the basis for dynamic method calls, objects&inheritance,
callbacks, events etc.

I have already condensed down my functions to work with the minimal cmake
script statements possible the only way to further improve is by creating a
C/C++ cmake command.  The problem is: I have so many function calls that
the time it takes is not negligable any more

I guess the only viable and platform independent solution is - as you wrote
- to create a cmake with some custom command which replaces the users
current cmake.


Performance Comparison (cmake code):

  timer_start(t1)
  foreach(i RANGE 0 10000)
    map_set(asd "${i}" "${i}")
  endforeach()
  timer_print_elapsed(t1)

  ## almost equivalent code
  timer_start(t2)
  foreach(i RANGE 0 10000)
    set_property(GLOBAL PROPERTY "asd.${i}" ${I})
    set_property(GLOBAL APPEND PROPERTY "asd" ${i})
  endforeach()
  timer_print_elapsed(t2)


  timer_start(t3)
  foreach(i RANGE 0 10000)
    eval("")
  endforeach()
  timer_print_elapsed(t3)


output:

t1: 2038 ms
t2: 204 ms
t3: 9424 ms


On Wed, Feb 25, 2015 at 1:21 PM, David Cole <DLRdave at aol.com> wrote:

> You could patch the executable to make cmLoadCommandCommand return
> true from IsScriptable... but if you're going to the trouble of
> patching CMake anyhow, why not simply build your loadable command
> directly into CMake...?
>
> The other thing might be to mention specifically what the performance
> problem is on the mailing list here to see if anybody has any ideas
> how we could make things faster..... And totally preclude your need to
> load an additional command in the first place.
>
> Or profile it and submit a patch to improve the performance in this
> situation.
>
>
> HTH,
> David C.
>
>
>
> On Wed, Feb 25, 2015 at 5:46 AM, Tobias Becker <becker.tobi at gmail.com>
> wrote:
> > Hi
> >
> > I've been working on an open source project which provides alot of extra
> > cmake (in pure cmake) https://github.com/toeb/cmakepp.  I am however
> hitting
> > a performance bottleneck and want to get around that by using
> load_command
> > (I know it is discouraged) however I have the problem that it is not
> > scriptable and all of my functions need to be available in script mode.
> >
> > Is there a way to load compiled commands into cmake after it was
> compiled?
> > (I have even thinking about patching the executable to make
> > cmLoadCommandCommand return true in its IsScriptable method)
> >
> > But there should be a simple way?
> >
> >
> > Cheers,
> >
> > Tobias
> >
> > --
> >
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20150225/9071a30d/attachment-0001.html>