I've did a test for performance issues caused by GC and memory consumption.
My test run on linux, node v0.8.5
the code:
var obj_num = 500;
var fill = {}
>
> for (var i = obj_num; i >= 0; i--) {
>
> fill["fill string***" + i] = "fill string" + i;
>
> };
>
> setInterval(fu
You are using object representation that is not really GC friendly.
Split you array into pieces (build B-tree like data structure) and you
will see GC pauses that are smaller by orders of magnitude.
Vyacheslav Egorov
On Wed, Nov 7, 2012 at 2:35 AM, darcy wrote:
>
> I've did a test for performan
split the object to 4, but nothing changed.
var obj_num = 500;
var split = 4
var fill = [];
for (var s = split; s > 0; s--) {
fill[s]={};
for (var i = obj_num/split; i > 0; i--) {
fill[s]["fill string***" + i] = "fill string" + i;
};
}
setInterval(function (
Pauses that follow initialization will actually become much smaller
(given that you disable idle notification that are abused by node).
Pauses during initialization of your test are irrelevant because your
allocation rate is not at the realistic level.
It is highly unlikely that your application
I'm not focus on the initialization time, but GC impact in large memory
usage cases.
In the test case, I used 850MB memory, which is normal for a net server
application, the GC takes 5*450ms and 2*3050ms periodically(every tens of
seconds).
I think there should be some way to imporve it.
At leas
You should not see any big GCs if you disable idle notifications that are
overstressed by node.
Vyacheslav Egorov
On Nov 8, 2012 6:14 PM, "darcy" wrote:
> I'm not focus on the initialization time, but GC impact in large memory
> usage cases.
> In the test case, I used 850MB memory, which is norm
