summaryrefslogtreecommitdiffstatshomepage
path: root/3rdparty/sol2/docs/source/performance.rst
diff options
context:
space:
mode:
author Miodrag Milanovic <mmicko@gmail.com>2016-11-06 10:05:36 +0100
committer Miodrag Milanovic <mmicko@gmail.com>2016-11-06 10:05:36 +0100
commitc2a75cb1799a31aa5687e576d1c0bdd50825fded (patch)
tree59144f444d666ae20ac8fb2bc4e4553d330945ca /3rdparty/sol2/docs/source/performance.rst
parentfffd464d345a6368cda7d90945d3409151218a06 (diff)
Updated sol2, made lua console not crash for nil data (nw)
Diffstat (limited to '3rdparty/sol2/docs/source/performance.rst')
-rw-r--r--3rdparty/sol2/docs/source/performance.rst1
1 files changed, 1 insertions, 0 deletions
diff --git a/3rdparty/sol2/docs/source/performance.rst b/3rdparty/sol2/docs/source/performance.rst
index cdfaa9614e6..534ab7e5a3e 100644
--- a/3rdparty/sol2/docs/source/performance.rst
+++ b/3rdparty/sol2/docs/source/performance.rst
@@ -7,6 +7,7 @@ things to make Sol as fast as possible
As shown by the :doc:`benchmarks<benchmarks>`, Sol is very performant with its abstractions. However, in the case where you need every last drop of performance from Sol, a number of tips and API usage tricks will be documented here. PLEASE benchmark / profile your code before you start invoking these, as some of them trade in readability / clarity for performance.
* If you have a bound function call / bound member function that you are going to call in a very tight, performance-heavy loop, considering using :doc:`sol::c_call<api/c_call>`
+* Be wary of passing by value / reference, and what it means by reading :ref:`this note<function-argument-handling>`.
* It is currently undocumented that usertypes will "inherit" member function / member variables from bound classes, mostly because the semantics are unclear and it is not the most performant (although it is flexible: you can register base classes after / whenever you want in relation to the derived class, provided that derived class has its bases listed). Specifying all member functions / member variables for the usertype constructor / ``new_usertype`` function call and not relying on base lookup will boost performance of member lookup
* Specifying base classes can make getting the usertype out of Sol a bit slower since we have to check and cast; if you know the exact type wherever you're retrieving it, considering not specifying the bases, retrieving the exact type from Sol, and then casting to a base type yourself
* Member variables can sometimes cost an extra lookup to occur within the Lua system (as mentioned :doc:`bottom of the usertype page<api/usertype>`); until we find out a safe way around this, member variables will always incur that extra lookup cost