It's been quite a few months since I last did a benchmark, a long long time, so I've gone through the benchmark code and fixed it up, so that we can take a look at which areas have the most room for improvement.
The results may vary from computer to computer, it drops down to about 50k when I have Chrome shut, and I can probably close even more things, but I'm more interested in what I can improve than precise numbers here.
//gosora-project.com/attachs/1cae27dfe1406858bef13a4605df8679e58eb0567ed92699ab421b67da38275f.png
To explain the benchmark, the ops in the ops/ns bit are basically calls to the route. Each call to the route is one op, simple right?
The number to the left of the number of ops is the number of times that the benchmarker has called that function, faster functions are called more times to get a more precise result.
The stuff to the right of the ops per nanosecond are things related to memory like the number of memory allocations and the number of bytes per op (I'm not exactly sure what that means exactly myself, but I have a inkling of an idea of what it is, definitely memory related).
Topics refers to /topics/ which is also / by default, although you can change that to /forums/, if you like that better. And Forums refers to /forums/
Topic refers to /topic/1, the alt versions are to run the same benchmark again, as I was seeing some screwy results before, usually indicative of errors, but that's been fixed now.
In addition, we have data for how long it takes to fetch a user from memory (UserGet), and how long it takes to fetch the same user from the database (UserBypassGet).
First, we'll turn our attention to the routes, as this is where we can get the biggest gains.
As we can see from the benchmark, /forums/ is six times faster than /topic/ which in turn is five times than /topics/... Approximately. I'm eyeballing, so it might be slightly off, but that's the gist of it.
Interesting, right? Well, why is /topics/ so slow and /forums/ so fast. This is because /forums/ is served entirely from memory, while /topics/ consults the database for information, /topic/ is actually a hybrid and it's architecture is slightly different.
While things have shifted here and there and we fixed a problem with /topics/ growing endless a few months back due to the lack of pagination, it is still in a very... undesirable position, as it's one of the top routes surpassing even the traffic of /topic/
In addition to that, it's actually fairly easy to optimise, very easy in fact. But how will we do it? That's easy. We're going to cache the data, do we really need to fetch the data every request? Even if it changes once or two in half a hundred milliseconds, does it matter?
We're going to cache it. We'll fetch the data once every half a second, and then we'll just work with that until the next tick, and then we'll fetch it again. Rinse and repeat unto perpetuity.
By doing this, we should be able to bring the sluggish /topics/ down from a slow 300 microseconds (my competitors would hate to see me call that slow, but who can ignore a big optimisation staring them in the face?), oops more like 400 microseconds, down to a more manageable 10 microseconds.
Perhaps, not exactly, I'd love it to be faster than /forums/, but around there. In other words, we're going to make /topics/ faster by a factor of 40, an incredible improvement and it won't even take that long, more on this in the coming days.
The results may vary from computer to computer, it drops down to about 50k when I have Chrome shut, and I can probably close even more things, but I'm more interested in what I can improve than precise numbers here.
//gosora-project.com/attachs/1cae27dfe1406858bef13a4605df8679e58eb0567ed92699ab421b67da38275f.png
To explain the benchmark, the ops in the ops/ns bit are basically calls to the route. Each call to the route is one op, simple right?
The number to the left of the number of ops is the number of times that the benchmarker has called that function, faster functions are called more times to get a more precise result.
The stuff to the right of the ops per nanosecond are things related to memory like the number of memory allocations and the number of bytes per op (I'm not exactly sure what that means exactly myself, but I have a inkling of an idea of what it is, definitely memory related).
Topics refers to /topics/ which is also / by default, although you can change that to /forums/, if you like that better. And Forums refers to /forums/
Topic refers to /topic/1, the alt versions are to run the same benchmark again, as I was seeing some screwy results before, usually indicative of errors, but that's been fixed now.
In addition, we have data for how long it takes to fetch a user from memory (UserGet), and how long it takes to fetch the same user from the database (UserBypassGet).
First, we'll turn our attention to the routes, as this is where we can get the biggest gains.
As we can see from the benchmark, /forums/ is six times faster than /topic/ which in turn is five times than /topics/... Approximately. I'm eyeballing, so it might be slightly off, but that's the gist of it.
Interesting, right? Well, why is /topics/ so slow and /forums/ so fast. This is because /forums/ is served entirely from memory, while /topics/ consults the database for information, /topic/ is actually a hybrid and it's architecture is slightly different.
While things have shifted here and there and we fixed a problem with /topics/ growing endless a few months back due to the lack of pagination, it is still in a very... undesirable position, as it's one of the top routes surpassing even the traffic of /topic/
In addition to that, it's actually fairly easy to optimise, very easy in fact. But how will we do it? That's easy. We're going to cache the data, do we really need to fetch the data every request? Even if it changes once or two in half a hundred milliseconds, does it matter?
We're going to cache it. We'll fetch the data once every half a second, and then we'll just work with that until the next tick, and then we'll fetch it again. Rinse and repeat unto perpetuity.
By doing this, we should be able to bring the sluggish /topics/ down from a slow 300 microseconds (my competitors would hate to see me call that slow, but who can ignore a big optimisation staring them in the face?), oops more like 400 microseconds, down to a more manageable 10 microseconds.
Perhaps, not exactly, I'd love it to be faster than /forums/, but around there. In other words, we're going to make /topics/ faster by a factor of 40, an incredible improvement and it won't even take that long, more on this in the coming days.