View Single Post
02-24-17, 06:35 AM   #15
kurapica.igas
A Chromatic Dragonspawn
Join Date: Aug 2011
Posts: 152
Originally Posted by SDPhantom View Post
When you place one layer of abstraction on top of another, you increase the overhead cost of running code. While this would be an interesting project using the standalone interpreter, it's a completely different situation implementing this in an environment where performance is critical.
The environment is just a table, each Lua function has its own reference to an environment, so there is no different you run a function whose env is a module, whose env is the _G.

The main issues here is accessing features in the function, if the feature is defined as local or existed in the module, the performance's the same like the global functions(no __index call). If the feature not existed, the module should access it from its parent module or the _G, it's the condition that would hit the performance(has __index call)

So the module will save the features to itself when it get them from parent module or _G. And it'll get it directly at the next time, there is no performance loss again(no __index call next time). Those features are commonly functions, tables and some const values.

Call object's methods always would cost a little more than pure Lua tables, but does it really matter, in a Scorpio module, the main logics are normally pure Lua codes(the functions for events, hook, slash cmd and etc, they are also registered to the core system as functions, they are called directly).

Another part for the performance is about the FPS, to gain a good performance, we need control the running time between two frames, if some functions run too long, the game will freeze, so we need to control how they working no matter it's pure Lua or not.

An important system in Scorpio is the task scheduling system, it provide several functions used to control threads, also will control the performance of those thread tasks based on their running times.
  Reply With Quote