4

So I have an object as follows:

var data = [
    {
        unmatchedLines: [], //possible big array ~700+ lines per entry
        statusCode: 200,
        title: "title",
        message: "some message",
        details: [],
        objectDetails: []
    },
    {
        //same object here
    }
];

This array gets filled by service calls and then looped through for merging the output before sending this result back to the frontend.

function convertResultToOneCsvOutput(data) {
    var outPutObject = {
        unmatchedLines: [],
        responses: []
    };
    for(var i = 0; i < data.length; i++) {
        if(data[i].fileData) {
           outPutObject.unmatchedLines = outPutObject.unmatchedLines.concat(data[i].fileData);
        }

        outPutObject.responses.push({
            statusCode: data[i].statusCode,
            title: data[i].title,
            message: data[i].message,
            details: data[i].details,
            objectDetails: data[i].objectDetails,
        })
    }

    return outPutObject;
};

Now I was first using delete to get rid of the unmatchedLines from the data object so that, in stead of creating a whole new object and pushing this to the output I could do:

 delete data[i].unmatchedLines;
 outPutObject.responses.push(data[i]);

But then I read that delete is very slow and stumbled upon a post stating that putting this to undefined in stead of using delete would be faster.

My question:

What is better to use in the end? delete, setting to undefined or creating a new object in itself like I am doing right now?

Tikkes
  • 4,599
  • 4
  • 36
  • 62

2 Answers2

9

Neither is "better."

It is true that when you delete a property from an object, on many modern engines that puts the object into a slower "dictionary mode" than it would be if you didn't delete the property from it, meaning that subsequent property lookups on that object (data[i] in your case) will be slower than they were before the delete. So setting the property to undefined instead (which is not quite the same thing) may be appropriate in those very rare situations where the speed of property access on the object matters.

T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
  • 2
    Just out of interest is this `dictionary` mode only temporary until the GC runs or is it a permanent thing for the lifetime of the object? – ste2425 Jul 26 '16 at 08:32
  • isn't `null` better than `undefined`? – Ceylan Mumun Kocabaş Jul 26 '16 at 08:32
  • What about creating the new object and pushing that? Is that going to be the same thing and setting the `undefined`? – Tikkes Jul 26 '16 at 08:35
  • 3
    @ste2425: Lifetime of the object. Modern JavaScript engines turn objects into instances of runtime-generated classes, producing subclasses when you add properties; *removing* properties is unusual and changes the nature of the object. – T.J. Crowder Jul 26 '16 at 08:36
  • 2
    @CeylanMumunKocabaş: No. You can use an value you want, but `null` isn't better than `undefined`. `undefined` has a slight advantage over `null` in that the result of reading the property is the same (`undefined`) as when you don't have the property at all, but again, you can use any value you want. – T.J. Crowder Jul 26 '16 at 08:37
  • @Tikkes: It won't be the same thing, but it will avoid the issue with `delete` slowing property access on the object down. – T.J. Crowder Jul 26 '16 at 08:37
2

It could be true, but it really depends on the length of the list, however:

any performance difference between the two techniques is going to be immeasurably small in any typical case.

( more info about delete )

Anyway: if you really need extra performance, you should consider dealing with clones and an immutable data-set ( more info about immutable performances )

Community
  • 1
  • 1
Simone Poggi
  • 1,448
  • 2
  • 15
  • 34
  • 1
    This is extra info and is useful in turn, I really would like to know why the downvote was placed... – Tikkes Jul 26 '16 at 09:06