header for response.writeHead() - best way to remove?

[P. Douglas Reeder]

I have the following code to write 304 Not Modified responses.  Headers are written by various methods and passed along in the headers variable, which is used as a hash.  HTTP 1.1 forbids 304 responses from returning entity headers, such as Expires.  The obvious way to keep such headers out of the response is the delete operator (as shown).  However, the delete operator is inefficient, and generally disreccomended for performant V8 JavaScript. Setting headers.Expires to undefined or null just sends the header as "Expires: undefined" or "Expires: null".  Delete is used at most once per HTTP request, so it's probably fine, but is there a better alternative?

if ( (ifModifiedSince || ifNoneMatch) &&

(!ifModifiedSince || stats.mtime.valueOf() === ifModifiedSince) &&

(!ifNoneMatch || ifNoneMatch.indexOf(headers.ETag) >= 0) ) {

console.info("Not Modified:", interim.filePath);

// entity-headers such as Allow, Content-*, Expires, and Last-Modified are not permitted.

delete headers.Expires;

response.writeHead(304, headers);

response.end();

return;

}

[Mark Hahn]

> However, the delete operator is inefficient, and generally disreccomended for performant V8 JavaScript.

Surely there wouldn't be enough deletes per request to be able to
notice a performance hit. I think you are comparing microseconds to
milliseconds.

[Tim Caswell]

The place where I avoid delete in node code is in "class instances".
(where "class" means a constructor and the "instance" is the result
of using `new`) From my understanding of the VM, delete causes V8 to
bail out of the hidden classes optimizations making all property
lookups much slower forever on that object. So I only delete on
objects that are pure data structures and not on instances of classes
that I'll have thousands of similar objects. Someone more familiar
with the current state of V8 can comment more intelligently.

> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en

[Mark Hahn]

FWIW, I'd put that concern in the "don't optimize too early" category.
My personal technique is to code the easiest way possible, see if
there are speed problems (which is rare) and then fix slow parts.
YMMV.

I know you didn't ask my opinion, just saying. I'm sorry I can't
answer your real question.

[P. Douglas Reeder]

Given the results at http://jsperf.com/test-v8-delete/2 it looks like delete is something to avoid in loops if you can, but OK to use generally.