Investigate overall performance between the bindings and rlua

[dariusc93]

In dd785b44b0c0385f5458d62b4b0898dd91759bc5 , I notice a huge performance hit that is even traced back before the implementation in that commit that causes the function to operate slowly. This could be due to the way rlua works, however after some thought, this does make me wonder if this same issue also affects other bindings, in which case would affect anything using torchbear, especially when it comes down to the matter of performance. Eg, I took a small script I found that reads data from a file a few thousand times. (data.txt can be random data up to about 200kb, but larger if you prefer)

local f = io.open('data.txt', 'rb')

s = os.time()
for i=1,5000 do
      f:read(200*1024)
      f:seek("set")
end
print("Lua fs took: " .. os.time()-s)

This only took a couple of seconds, which is expected, however with the fs binds (pre or post dd785b44b0c0385f5458d62b4b0898dd91759bc5) there is a huge difference

local f = fs.open("data.txt")
s = os.time()
for i=1,5000 do
    f:read(200*1024)
    f:seek("start", 0)
end
print("Rust fs took: " .. os.time()-s)

This took way too long to complete, which makes me wonder if there is something going on with the implementation of fs bindings. Decreasing the iteration down to 100 only took a few seconds to complete vs the ms that it took to complete in lua io functions. I also tested the memory binding as well and the performance is slightly better but just as the same as the fs binding. A pure rust implementation of the above script works as expected and completes in less than a ms

use std::{
    fs::File,
    io::{SeekFrom, prelude::*}
};

fn main() {
    let mut fs = File::open("data.txt").unwrap();
    let mut bytes = vec![0u8; 200*1024];

    for _ in 0..5000 {
        fs.read_exact(&mut bytes).unwrap();
        fs.seek(SeekFrom::Start(0)).unwrap(); 
    }
}

Since then, I have been slightly investigating what could be affected by this issue and one thing I remember was #113 and that makes me wonder if it is rlua itself and the way it handles any functions created. It would somewhat make sense that it could be rlua itself due to its design and how it works with embedded lua via ffi and there may be a few ways to improve the way rlua handles everything but some may be in a unsafe manner, and in reality this would require further investigation as well as finding out the real impact in performance between rlua and other bindings.

This was tested in both rlua 0.15 and 0.16.

Could possibly be linked to #217 (though in that issue, what is measured is mainly the web side of torchbear which main impact is that it doesnt scale like a native actix or tokio application could).

[kyren]

Hey, this is the author of the rlua crate. I don't know what specific performance issues you're experiencing, but if you can narrow this down to something in rlua, especially if it's something that changed from a previous version of rlua, I'll do my best to fix it.

Please open an issue on rlua if you think this is something that rlua can do better, and we can discuss it there!

I'm unfamiliar with torchbear though, so if you can't come up with an isolated example, you're going to have to help me through the torchbear specific parts of it.