Weak references. Does node-weak and other simliar libraries, add significant overhead?

[Fredrik O]

Hi,

Does anyone know if it is safe, for performance reasons to heavily use the npm module: "node-weak" and similar libraries? Does it add significant overhead?


Thanks in advance

[Diogo Resende]

You could use ES6 WeakMaps.

https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/WeakMap

-- 

Diogo Resende

--
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

[Nathan Rajlich]

I've only really used it for testing and tracking down memory leaks,
but I know that "hook.io" has used it as a dependency in the past, and
that "dnode" does currently. What exactly is your use case?

[Fedor Indutny]

This actually depends on how much are you going to use them.

Few thousands objects are probably ok, but millions will slow down GC significantly.

Cheers,

Fedor.

[Fredrik O]

Thanks for your responses, all!

I use it too support a simple (C++) RAII functionally, to reclaim resources, both external and internal resources. I believe it is good idea. It allows a resource, even if an exception get thrown be reclaimed. I simply code in mind that a exception can get thrown almost anywhere. For example this code is not safe:

var obj = pool.create(); //may be a connection pool
// code here which may throw an exception
pool.release(obj); //may not ever be reached, if the code before thrown an exception, therefore not safe

The regular exception handling will not be a solution, because of the asynchronous design of node.js. However, if I use weak references, I can ignore the call to "release" if I want too. This feature is specially useful for implementing multiple design patterns, for example flyweight:

//copy of C++ boost.flyweight, but in JavaScript
var obj = flyweight("This string will only exist once in memory, so even if I create thousands of them, will no memory increase significantly happen");//may be of any type
console.log(obj); //we can treat the object just like the object we constructed it with: "string", with the exception it is read-only.

When all references dies will the object be released automatically, and when we want to create a new instance will the library create a new cheap reference to the value already in memory. This would never be possible without weak references. I have actually created a module like this, which I plans to release to the public some time.

So in conclusion, I have started to use it whenever there I believe it fits, in multiple places, but I wonder if I need to worry about any significant performance degradation?

PS. How would weak maps be used to call a custom function on garbage collection?

What are your thoughts?

Thanks in advance!

[Rick Waldron]

On Monday, October 22, 2012 at 5:22 PM, Fredrik O wrote:

PS. How would weak maps be used to call a custom function on garbage collection?

I think you've misunderstood, WeakMaps don't facilitate this

Rick

 

 

What are your thoughts?

Thanks in advance!

[Fredrik O]

Thank you Rick, it was good to know.

Just for curiosity, what do you people thought, to emulate RAII within JavaScript for those object which need some clean up? Am I doing it completely wrong? I mean, an exception can easily get thrown in JavaScript and try..catch cannot catch error within callbacks. And domains just feel wrong. For those who does not know what RAII is, it is an automatic way to invoke a destructor when the object get out of reach, by normal control flow or an exception get thrown. See wikipedia: http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization

And Nathan (or if there is someone else which can do a serious guess), because you have not answered I assume it will be fine to use your library heavily. With heavily do I mean having around 10 000 concurrent weak objects alive. If you believe it would not be case, please let me know.

Thanks in advance.

[Nathan Rajlich]

I mean try it and find out :) If you run into problems, let us know!

[Marco Rogers]

Can you elaborate on "domains just feel wrong". I'm interested in how the domains api comes across. I've expressed my concerns with it in the past.

:Marco

[Bradley Meck]

Take it to a different topic if it becomes unrelated also.

[Rick Waldron]

WeakRefs are on the table for ES6... if someone here wants to write up a proposal (I'm looking at Nate) I will gladly champion it at the next TC39 meeting.

Rick

[Fredrik O]

I have created a new thread for this, see: https://groups.google.com/forum/?fromgroups=#!topic/nodejs/p7kfwcbJBxE

[Nathan Rajlich]

Rick, is there a template for proposals I should base it off of?

[Rick Waldron]

On Thu, Oct 25, 2012 at 1:03 PM, Nathan Rajlich <nat...@tootallnate.net> wrote:

Rick, is there a template for proposals I should base it off of?

Not really, a gist in markdown will be more then sufficient. 

Include a rationale (this is probably the easiest part) and ideally a summary of your experience with weak refs, v8 and how you made the two work together (ie. anything valuable that you learned here: https://github.com/TooTallNate/node-weak/blob/master/src/weakref.cc). 

Then a rough outline of a "possible" API, keep in mind this sort of thing will be grilled and bikeshedding will happen. Finally, a composition of proposed semantics.

Looking forward to seeing what you produce and I'll make sure its on the Nov meeting agenda

[Rick Waldron]

Also, take a look at these...

http://wiki.ecmascript.org/doku.php?id=strawman:weak_references

http://wiki.ecmascript.org/doku.php?id=strawman:weak_refs

Perhaps there is something that can built on top of, or an aspect you can prove/disprove?

Rick

On Thu, Oct 25, 2012 at 1:03 PM, Nathan Rajlich <nat...@tootallnate.net> wrote: