Breeze.js model library

Question

I face a memory issue when using big breeze.js entity list . I noticed it's because using this code in the knockout model library :

ko.extenders.intercept = function(target, interceptorOptions) {
        var instance = interceptorOptions.instance;
        var property = interceptorOptions.property;

        // create a computed observable to intercept writes to our observable
        var result;
        if (target.splice) {
            result = ko.computed({
                read: target  //always return the original observables value
            });
        } else {
            result = ko.computed({
                read: target,  //always return the original observables value
                write: function(newValue) {
                    instance._$interceptor(property, newValue, target);
                    return instance;
                }
            });
        }
        //return the new computed observable
        return result;
    };

Do you have any suggestion to do " instance._$interceptor(property, newValue, target);" without the ko.computed , it consumes alot of memory , if I comment the Ko.computed the memory decrease allot .

Thanks in advance ...

This is how the backing store works for Breeze.js. When you say it consumes a lot of memory are you talking about on a specific browser? I can't imagine any modern browsers facing memory issues with this. — PW Kad
Thanks for the reply . In IE it's extremely bad but also in other browsers , I profiled 1400 product entities in my application and the memory reduced from 139mb to 45 mob with and without the code above . — Wasim
I had problems as well with Breeze's memory usage. I couldn't find any work around that time. The only solution was to review my app design and use the minimum amount of data needed. — Razvan

Ward Ward · Accepted Answer · 2014-05-23T19:33:36

Not sure where to lay the blame here.

1400 entities doesn't sound like a large number to me. Something else seems wrong.

My crude arithmetic tells me you're incurring a ~100KB cost PER ENTITY for computed observables and 32KB per for regular observables. Both numbers are kind of obscene. Your Product types must be pretty wide too, eh? I'll bet your Product type has a large number of properties ... many of which might be irrelevant to your client app.

What is Breeze doing and why?

The use of Knockout requires construction of an observable (computed or otherwise) for every property of every entity on the grounds that you might bind to any of them. We use computeds in order to perform other Breeze functions (e.g., validation, navigation wire-up) in addition to observability.

I do find myself wondering why computed observables are 3x as expensive as regular observables. Is that the Knockout price? Is Breeze adding to that cost somehow? I do not know.

I suppose Breeze might attach its own event handlers to regular observable properties instead of using computeds. I don't know if that would lead to timing errors or loss of functionality (e.g., certain transforms we do on the data during set). I don't know if it would save space once you added the weight of our handlers.

I suspect that the Breeze architect considered these issues carefully before going with computeds and did his best to minimize the weight of Breeze code in those computeds.

I can tell you that we're unlikely to look at this soon. If you see something yourself that seems particularly egregious, please let us know and we'll follow your lead.

What to do?

I think I'd look more closely at my Product entity to see if I could shave it down considerably ... at least for these use cases ... and consider how I could manage with fewer of them in cache at any one time (you'll be thinking about how to evict products from cache periodically as well).

Breeze.js model library

1 Answers

What is Breeze doing and why?

What to do?