使用全局变量和局部变量以及 require 的比较
2018-7-19 7:40:58
收藏:0
阅读:190
评论:1
有人告诉我使用全局变量是不好的,使用 require 获取局部变量是更好的设计。
我进行了一个简单的测试,以确定这两种方法之间是否有性能差异。
我的代码:
#include <lua.hpp>
#include <ctime>
#include <chrono>
void main()
{
lua_State *L = luaL_newstate();
luaL_openlibs(L);
lua_settop(L, 0);
//Script A
luaL_dostring(L, "package.preload['A'] = function () local A = {}\n"
"function A:mult(a,b) return a * b end\n"
"return A end");
std::clock_t startcputime1 = std::clock();
//Script B
for (int i=0; i<100000; ++i)
luaL_dostring(L, "local A = require 'A' A:mult(2,3)");
double cpu_duration1 = (std::clock() - startcputime1) / (double)CLOCKS_PER_SEC;
std::cout << "用时 " << cpu_duration1 << " 秒 [CPU 时钟] " << std::endl;
lua_close(L);
L = luaL_newstate();
luaL_openlibs(L);
lua_settop(L, 0);
//Script A
luaL_dostring(L, "A = {} function A:mult(a,b) return a * b end\n");
std::clock_t startcputime2 = std::clock();
//Script B
for (int i=0; i<100000; ++i)
luaL_dostring(L, "A:mult(2,3)");
double cpu_duration2 = (std::clock() - startcputime2) / (double)CLOCKS_PER_SEC;
std::cout << "用时 " << cpu_duration2 << " 秒 [CPU 时钟] " << std::endl;
lua_close(L);
}
结果:
用时 0.739236 秒 [CPU 时钟]
用时 0.479537 秒 [CPU 时钟]
如您所见,使用全局变量 A 比使用局部变量 A 和 require 更快。
这是否意味着如果性能是我的应用程序的重要因素,则最好使用全局变量共享数据呢?
点赞
评论区的留言会收到邮件通知哦~
推荐文章
- Lua 虚拟机加密load(string.dump(function)) 后执行失败问题如何解决
- 我想创建一个 Nginx 规则,禁止访问
- 如何将两个不同的lua文件合成一个 东西有点长 大佬请耐心看完 我是小白研究几天了都没搞定
- 如何在roblox studio中1:1导入真实世界的地形?
- 求解,lua_resume的第二次调用继续执行协程问题。
- 【上海普陀区】内向猫网络招募【Skynet游戏框架Lua后端程序员】
- SF爱好求教:如何用lua实现游戏内调用数据库函数实现账号密码注册?
- Lua实现网站后台开发
- LUA错误显式返回,社区常见的规约是怎么样的
- lua5.3下载库失败
- 请问如何实现文本框内容和某个网页搜索框内容连接,并把网页输出来的结果反馈到另外一个文本框上
- lua lanes多线程使用
- 一个kv数据库
- openresty 有没有比较轻量的 docker 镜像
- 想问一下,有大佬用过luacurl吗
- 在Lua执行过程中使用Load函数出现问题
- 为什么 neovim 里没有显示一些特殊字符?
- Lua比较两个表的值(不考虑键的顺序)
- 有个lua简单的项目,外包,有意者加微信 liuheng600456详谈,最好在成都
- 如何在 Visual Studio 2022 中运行 Lua 代码?

我将忽略我在评论中指出的有关基准测试的问题。我假设您进行了准确的基准测试,并确定全局变量更快。
为了值得这样做,您需要做的不仅仅是证明性能对您的应用程序很重要。您还需要证明模块本地变量访问引起的特定性能对您的应用程序很重要。大多数应用程序不会花费大部分时间访问本地变量。它们的性能问题通常来自算法、正在执行的进程、等待硬盘访问或类似的事情。
给您提供建议的目的是确保应用程序的正确性。通过将模块本地变量保留在其自己的表中,您使得一个模块不可能破坏另一个模块。因此,仅仅因为一次人为的测试而忽略这个建议而不知道它能否明显改善您实际应用程序的性能是不明智的。
或者,就像人们所说的那样,过早优化是万恶之源。