Blocking the event loop with for..in

Question

I would like to check a Javascript Object for unwanted properties with a schema definition for revalidator (https://github.com/flatiron/revalidator).

I came up with following snippet:

function strip(object, schema) {
    var strippedObject = {};
    for (var property in schema.properties) {
        if (schema.properties[property].type === 'object') {
            strippedObject[property] = strip(object[property], schema.properties[property]);
        } else {
            strippedObject[property] = object[property];
        }
    }
    return strippedObject;
}

This code copies the wanted properties and loops synchronously over the schema recursing into nested schemas.

I'm worried about blocking the event loop in this time.

Is this negligible as I'm not doing I/O?

EDIT

Thanks for the comments. Like jbaylina mentioned it is indeed the case that the schema is nested to a maximum of 2 levels with maybe around 10 properties each. Nevertheless I tried out using setImmediate an it works, but I would maybe iterate asynchronously when it really is a problem:

function strip(object, schema, callback) {
    var strippedObject = {};
    async.each(Object.keys(schema.properties), function (property, next) {
        if (schema.properties.hasOwnProperty(property)) {
            if (schema.properties[property].type && schema.properties[property].type === 'object') {
                strip(object[property], schema.properties[property], function (err, obj) {
                    if (err) return next(err);
                    strippedObject[property] = obj;
                    next();
                });
            } else {
                strippedObject[property] = object[property];
                next();
            }
        }
    }, function (err) {
        if (err) return callback(err);
        return callback(null, strippedObject);
    });
}

This looks really messy, but it works and passes the tests. What do you think about this solution?

Gabriel · Answer 1 · 2013-08-15T21:51:21.927

1

It is not negligible for large complex object graphs, because it is recursive. Since it is recursive you could easily wrap calling the next recursion inside a setTimeout or setImmediate to free up the event loop.

Re: Edit this looks good from a performance perspective. It looks like it could be refactored to be more readable but I think you have a solid grasp of the problem domain and the solution you have crafted.

edited Aug 15 '13 at 21:51

answered Aug 14 '13 at 17:11

Gabriel

18,322
2
37
44

+1 for setImmediate. It essentially takes the recursive call and puts it at the end of the loop stack so it maintains it's place in the loop but lets anything else it would be blocking through first. – James LeClair Aug 14 '13 at 17:13

score 0 · Answer 2 · edited May 23 '17 at 10:25

0

Unless the schema has thousands of properties, it should not be a problem. Try to measure the time the subrutine takes in the worst case in a "standard envirotment" If that time is not acceptable, you can split this loop in multiple pieces. See Prevent long running javascript from locking up browser

edited May 23 '17 at 10:25

Community

1
1

answered Aug 14 '13 at 17:45

jbaylina

4,408
1
30
39

This is about node, not the browser but you're maybe right as the schemas are small. – thertweck Aug 14 '13 at 18:41

Blocking the event loop with for..in

2 Answers2