LuaJIT on main thread much slower on Mac after window init

support
1

i am creating a cross-platform game where I am embedding LuaJIT. i have been scratching my head because i discovered that, on Mac, as soon as i create the window with glfwCreateWindow, LuaJIT is way slower… but if i invoke the same Lua script before I do any GLFW initialization, it is lightning fast. furthermore, this doesn’t occur on Windows. basically everything i’ve read says i should use LuaJIT from the main thread and not try to mess with it. i could set up a minimal example repo at some point if that would be helpful. i have triple-checked i am running with all optimizations enabled on every platform i compiled and tested on.

i think it is probably Cocoa’s fault. i found this old issue that feels related but i could be wrong

am i missing an obvious solution here? perhaps there’s a silver bullet in here but i haven’t explored it too much. i was hoping to get away with a single-threaded application on all platforms… not looking for a comprehensive solution from someone — just hoping someone with more experience than me could tip me off to a useful resource, or tell me i am doing the wrong thing with regard to embedding Lua in a GLFW application. thank you!

2

Another thing to try could be running GLFW from LuaJIT: GitHub - sonoro1234/LuaJIT-GLFW: OpenGL and GLFW bindings for LuaJIT

3

Hi @bandaloo and @sonoro1234,

Welcome to the GLFW forum!

It’s difficult to understand what’s going on without a bit more information. For example, are you timing a running a single Lua script function or are you running Lua every frame and looking at the overall performance? I would recommend timing the call itself to understand where any performance difference is coming from, as naturally if you are running the code whilst rendering the window then the window handling code will eat up some performance, and vsync could lock your framerate.

Things I would do:

Time the Lua script function call:

double startTime = glfwGetTime();
RunLuaScript(); // what ever you need to run your script ( lua_pcall etc.)
double endTime = glfwGetTime();
printf("Time Taken: %f\n", endTime-startTime );

This should be the same both before and after creating a window. However running a standard window loop will take up some time, and vsync could cause glfwSwapBuffers to also take up some time. To check this you could add further profiling:

    /* Loop until the user closes the window */
    while (!glfwWindowShouldClose(window))
    {
        double startTimeLua = glfwGetTime();
        RunLuaScript(); // what ever you need to run your script ( lua_pcall etc.)
        double endTimeLua = glfwGetTime();
        printf("Time Taken Lua: %f\n", endTime-startTime );

        /* Render here */
        double startTimeRender = glfwGetTime();
        glClear(GL_COLOR_BUFFER_BIT);

        /* Swap front and back buffers */
        glfwSwapBuffers(window);

        /* Poll for and process events */
        glfwPollEvents();
        double endTimeRender = glfwGetTime();
        printf("Time Taken Render: %f\n", endTime-startTime );
    }

You could also investigate using a profiling tool, for an example see my enkiTSExamples for how to use two simple profilers with my open source tasking library.

Once you have this information (or if you have it already) reply to this thread and we can help you come up with a solution.

I’m not sure this is directly related, other than forcing you to call glfwPollEvents() and other functions from the main thread.

1 Like
4

thanks for the info! yep, that code example is almost exactly how i tested, and i found that running the lua script was significantly slower after initializing the window. i’ll dig further and i’ll update this thread with a clear, minimal code example and results on different platforms. enkiTS looks useful

thanks again; i have absolutely no pride about this, so i really hope it’s something naive i am doing!