Efficiently binding a LOT of things to sol #436
Comments
I'm afraid we don't supply a lower-level binding as -- surprisingly -- we are only doing the barest minimum to actually bind things with simple usertype's As a side note, I see a "#pragma once" in there. If this is in a header, you should move it to single compilation unit immediately, or to multiple compilation unit if you're not using the 64-bit Toolset to enable having greater than 4 GB of compiler space available and your bindings are truly that massive (assuming Visual Studio: if you're using more than Visual Studio, you'll be fine: gcc/clang will just attempt to consume all available RAM by default). This will mean that this only gets compiled once in a while, whenever the bindings are updated, rather than with every build. Finally, the only thing you can do that's "lower level" is... well, setting up your own kind of usertype. Since you're automatically generating the bindings, you can use pieces and parts of sol2 (like tables, function binding support, Still, templates ultimately cause the compile-time churn because it's "generating" things at compile-time. If you want to hammer it down, then you can essentially write chunks of the wrapper yourself and stamp them out ahead-of-time. Unfortunately, "export" templates were dropped from C++ as a feature, so I can't even use that for this niche use case... |
Alright, thanks. It's included in a single compilation unit at the moment, the |
As a side note: you know a LOT of what you're doing before-hand. The distinct thing about all the templates you're working with is that they're generating new function types for each distinct signature (of which there are a LOT of distinct ones). You can cut down on this by "hand-crafting" your own metatable. You can get one started in sol2 by doing the usual
Now, here's where things get tricky. You use
This is essentially how member functions are handled. There are special cases I'm not talking about here because there's a LOT of those but this is probably what you want. Then, you can add it to the usertype metatable at runtime using
You can get even more performance and save Lua serialization space by using
Remember The reason sol2 can't dump out this code for you to save in a serializable format is because we do this at compile-time, on-demand, when you hit F7/Ctrl+B (whatever your build button is). This means it keeps itself updated and doesn't require you to re-serialize crap. But since you're running a generator before-hand, you can write your own generator on top of sol2: do feel free to use it as you wish! And let me know how this goes: if this becomes the case, I might make this issue part of the documentation if there's any success in reducing compiler overhead. Also, @OrfeasZ @eliasdaler maybe you two would want to take a look at this too, since it might be of interest to you. It's about as close to "internals documentation" as you can get, really...! Good luck. |
Added a link to here from the docs, since it might as well be there in case somebody wants to try their hand at using sol2 on a more "manual" level: http://sol2.readthedocs.io/en/latest/compilation.html#compile-speed-improvemements |
Just out of curiousity, what makes sol::property so complicated? |
This creates a terribly "fun" problem when trying to keep both performance and have the damn thing work. You can't just dump a bunch of functions into Lua's metatable. You have to bind That is, of course, just the beginning. Did you want to support base classes? How about calling a variable like a function? How about using functions as variables ( They want to bind function objects, variables, things that may or may not have annnnything to do with the class they're being bound too, but provide a value in a consistent and easy way that looks like it comes "from the instance". Oh, and don't forget people want to add stuff at runtime, because the system wasn't complicated enough already: which, by the way, how do you know that someone's adding a variable versus a function at runtime? Finally, now that you've created a system that can handle all of that, correctly, and the bug reports stop...! Is it fast ? |
I understand your pain. Sol2 is great. Thanks for the fast response! Also, it supports write-only? Interesting. |
Oh, one more question. It's to do with the above code you provided as an example of a lua_CFunction that makes use of sol. What would be the best thing to do if required arguments are either of the wrong type or missing? I.e. what would the safety checks you omitted look like? I know about luaL's checknumber, checkstring etc. I'm wondering if there are other things to do. For now, I'm just doing |
It does support write-only.
There's also some other checks we do for when people do |
Alright, I'll use the The generated functions are nice. Currently, they look like this (though there are some mistakes such as the
|
That was pseudo code, but |
Oh. Alright. |
compile speed is nightmare. my binding files has about 4000 lines and most of them are coded manually .... |
@guijun Place all your bindings in either a single .cpp file or multiple .cpp files. Only update the files when you need to make a change to the binding. This will keep your compile speeds lower and only invoke the pain when you actually change the bindings. I am working on new ways to bind things since compile times has become more or less a pain for most users. I just haven't been able to write one that has the same performance as |
Hi, Thanks. I have to keep it onhold and continue when your new release the speed boosted build~ |
Hi,
As you might know I have been writing a lua binder for the Unreal Engine using this library.
Currently, I am binding everything by creating simple usertypes (
create_simple_usertype
), adding functions/members one by one viaset
, and adding that to the lua state directly. This reduces compile time a lot and fixes all the errors caused by the compiler running out of space.However,
set
still generally goes through more than 40 levels of template code. This means that one engine module (for example, the very large core module with 1,456 classes) will take a very long time to compile and debug. I am aware that sol is made to simplify binding things to lua, but would at this point be very interested in knowing if any lower level methods of binding a user type are available.I have already done several things to mitigate the long compilation, such as duplicating the default UHT behavior of splitting generated source files into multiple compilation units. However, this doesn't solve the problem of set being very complex. With the information we already use to create the bindings (information that comes from UHT before our generator runs) we can probably provide much of the information that is currently being found automatically.
Our autogenerated binding functions currently look like this:
The text was updated successfully, but these errors were encountered: