Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Destroying Blaze templates with many sub-templates freezes browser #7326

Closed
arggh opened this issue Jun 29, 2016 · 0 comments
Closed

Destroying Blaze templates with many sub-templates freezes browser #7326

arggh opened this issue Jun 29, 2016 · 0 comments

Comments

@arggh
Copy link
Contributor

arggh commented Jun 29, 2016 •
edited

Running newest Meteor 1.3.4.1 (or an older one if you wish), destroying a Blaze-template with many child/sub-templates causes a complete browser lock down for several seconds.

All that's needed is a basic table-element with ~few hundred rows and a couple of columns on each. Rendering the table happens in a user friendly manner, but once it's being teared down the user experience crumbles - the browser freezes completely, making users click repeatedly on the button/link/toggle thinking their clicks are not registered.

Reproduction can be found here: https://github.com/arggh/blaze-tmpl-destroy/tree/nosubs

The issue was already reported (and closed without resolution or fixes) at #4352 and then resurrected in the meteor/blaze -repository: meteor/blaze#44.

I realize that Blaze has been split to it's own repository, but there's not much happening over there and the repository's maintainer stated that the transition is not yet complete, advising to post the issue in both repos.

I think this is such a drag and it's not really that uncommon to have a table with few hundred rows on a website, so maybe it should be fixed?
arggh added a commit to arggh/meteor that referenced this issue Jun 29, 2016
@arggh
Set stopped computation to null instead of delete (meteor#7326)
575d2b2 
Delete can be very slow. Setting the stopped computation property to null instead brings a speed gain of 3-10x.

http://bertanguven.com/preventing-memory-leaks-in-javascript-null-vs-delete
@arggh arggh mentioned this issue Jun 29, 2016
Merged
benjamn pushed a commit that referenced this issue Jul 12, 2016
@arggh @benjamn
Set stopped computation to null instead of delete (#7326) (#7328)
768d82e 
* Set stopped computation to null instead of delete (#7326)

Delete can be very slow. Setting the stopped computation property to null instead brings a speed gain of 3-10x.

http://bertanguven.com/preventing-memory-leaks-in-javascript-null-vs-delete

* add generated npm-shrinkwrap.json

* Remove computation tracking from Tracker.
@laosb laosb closed this as completed Aug 29, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@laosb @arggh