DeftJS 8.0-9.1Promise/Deferred Memory Usage

[ars265]

When using DeftJS 8.0 through 9.1 I'm seeing a significant amount of memory being used in the browser and not being released. I attempted to use done after the completion of my promises (in 9.0 and higher) but using DeftJS to create large numbers, in the thousands, and then performing them cause the application to stall. While my processor is exerted as I would expect, the memory usage climbs to about 800,000k before killing the site. Our application normally runs at about 100,000k to 180,000k. Is there any way to look into where Deft may be having problems?

[johnyanarella]

Hey Anthony,

Are you seeing this consistently with all browsers, or one browser in
particular? I had a report come in yesterday regarding a memory leak in
IE11 with a related Promise implementation.

-John

Anthony Sparks mailto:notifications@github.com
February 20, 2015 at 5:17 PM

When using DeftJS 8.0 through 9.1 I'm seeing a significant amount of
memory being used in the browser and not being released. I attempted
to use done after the completion of my promises (in 9.0 and higher)
but using DeftJS to create large numbers, in the thousands, and then
performing them cause the application to stall. While my processor is
exerted as I would expect, the memory usage climbs to about 800,000k
before killing the site. Our application normally runs at about
100,000k to 180,000k. Is there any way to look into where Deft may be
having problems?

—
Reply to this email directly or view it on GitHub
#137.

[ars265]

I'm currently finding it in Firefox 35.0.1 and Chrome 40.0.2214.111. IE also seems to slow but that is a bit harder to gauge accurately with lesser benchmarking tools in IE 9.

[ars265]

Also, I am using Deft.Chain.sequence if that helps. Are promises executed using sequence completed and freed after the execution of the sequence, or after the promise of the sequence has done called?

[johnyanarella]

Hey Anthony,

Hmm. The only internal references to those Promises are in callback
functions that are queued for execution and then subsequently freed.

I just did a quick test where I created 1,000,000 Promises and
immediately resolved each with individually allocated JSON payloads.
Profiling it in Chrome, when I trigger that action I see memory usage
spiking to 1082MB before dropping back to its original amount once the
browser gets around to performing garbage collection.

Could you elaborate a bit more about what you're doing when you see this
behavior? What are you passing to Deft.Chain.sequence()? Do each of
your Promises resolve with a large amount of data? Deft.Chain.sequence
aggregates and returns an Array of the results of all the specified
functions. Additionally, it creates a Promise to wrap the result of
your function and add a callback to perform that aggregation.

It might be that you need to schedule your work in smaller chunks, with
gaps of time in between to allow the browser time to schedule the
garbage collector.

Stepping back a bit, I'm kind of curious - what sort of
Promise-returning operations are you scheduling? Scheduling thousands
seems like a pretty extreme use case. :) How quickly do they return
and with how much data?

Best regards,

-John

Anthony Sparks mailto:notifications@github.com
February 20, 2015 at 5:53 PM

Also, I am using Deft.Chain.sequence if that helps. Are promises
executed using sequence completed and freed after the execution of the
sequence, or after the promise of the sequence has done called?

—
Reply to this email directly or view it on GitHub
#137 (comment).

Anthony Sparks mailto:notifications@github.com
February 20, 2015 at 5:17 PM

When using DeftJS 8.0 through 9.1 I'm seeing a significant amount of
memory being used in the browser and not being released. I attempted
to use done after the completion of my promises (in 9.0 and higher)
but using DeftJS to create large numbers, in the thousands, and then
performing them cause the application to stall. While my processor is
exerted as I would expect, the memory usage climbs to about 800,000k
before killing the site. Our application normally runs at about
100,000k to 180,000k. Is there any way to look into where Deft may be
having problems?

—
Reply to this email directly or view it on GitHub
#137.

[ars265]

John,

I'm using Deferreds and Promises to execute filtering and property calculations over a set of TreeModels ranging from 500 to 2000. I will say that some of these calculations can require a bit of searching. I'm using the Deft.Chain.sequence to execute the chain of promises in order since properties can be calculated based on the data from their parents.

Currently the work is being divided into chunks of about 50 nodes and I do have the ability to adjust to smaller sets, which I can test. The number of promises should be between 2 to 8 per set of 50 nodes. You are correct that I wouldn't think that this number of promises would cause an issue.

The only other thing that I might thing relevant would be that we are resolving or rejecting the deferred in a timeout. Below is a short example, this is to cause work to be continued without the browser alerting that the scripts have timed out:

var deferred = Ext.create( 'Deft.promise.Deferred' );

setTimeout( function() {

//call a function returning values
//deferred.resolve( values ) or deferred.reject();

//without a small break browsers might still find this processing quiet intense
// and not perform other updates such as UI updates.
}, 10 );

//return deferred.promise

If you have more questions about my use case I would be happy to provide what I can.