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.

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

Huge public columns hash #162

Closed
sfcgeorge opened this issue Apr 11, 2019 · 7 comments
Closed

Huge public columns hash #162

sfcgeorge opened this issue Apr 11, 2019 · 7 comments
Labels
enhancement New feature or request performance No effect on functionality, just on memory or speed performance

Comments

@sfcgeorge
Copy link
Contributor

sfcgeorge commented Apr 11, 2019

The database information Hyperstack includes on the page is huge for our app with >50 models. Noticeably slows down pageload.

https://gist.github.com/sfcgeorge/80bbb475e7613b85823a885cc1b2aedf

@Tim-Blokdijk
Copy link
Contributor

I get a 404 on your gist link?

@sfcgeorge
Copy link
Contributor Author

My bad, fixed. I've also just noticed that the public columns hash is actually included multiple times - once per mounted component! That's surely not helping the page size.

@catmando
Copy link
Contributor

@sfcgeorge - so you are mounting multiple components in the view?

A short term fix that is easy but not elegant is to manually put in some erb method to dump the hash and then patch it out of the hyperstack code.

For ease of initial integration render_component runs assuming its the only one on the page, so dumps the hash. IIRC I could not find any way to only do it once so to speak but I could be wrong about that too.

If one copy of the hash is still too big, perhaps it gets rendered as a seperate asset in production and the whole gzip mechanism compress it?

Let me know if you need assistance, but I'll assume you can work around it for now?

@catmando catmando added the enhancement New feature or request label Apr 15, 2019
@catmando catmando added this to To do in ALPHA to production via automation Apr 15, 2019
@catmando catmando added this to the alpha1.5 milestone Apr 15, 2019
@catmando
Copy link
Contributor

In the next point release we will do something to make this better:

  1. instead of just dumping the raw public columns data, we will put it in a minimalist data set that has only what Hyperstack needs.
  2. The dump will be in a standard format so it doesn't matter if rails changes how the columns data works, we will have a consistent API
  3. Either make it so it dumps once, (i.e. only on first component mount) and if not possible, then provide a mechanism to manually dump it.

@sfcgeorge
Copy link
Contributor Author

Yep, mounting multiple.

  1. Sounds great.
  2. Really good thought for stability.
  3. All I can think for automatically doing the right thing is a request local variable (if there is such a Rails thing... https://edgeapi.rubyonrails.org/classes/ActiveSupport/CurrentAttributes.html) or maybe even just an ivar @columns_data_rendered = true. Or a manual option ala render_component(schema: false)

@sfcgeorge
Copy link
Contributor Author

I added this patch to ComponentMount. Page size went from 739 KB to 317 KB, nice! An ivar feels a bit wrong but it works. (note it's the react_component method that's impacted by this, render_component in the controller is fine as there's only ever one).

def footers
  unless @hyperstack_footers_rendered
    @hyperstack_footers_rendered = true
    Hyperstack::Component::IsomorphicHelpers.prerender_footers(controller)
  end
end

@catmando catmando removed this from the alpha1.5 milestone Apr 23, 2019
@catmando catmando added the performance No effect on functionality, just on memory or speed performance label Jun 19, 2019
@catmando
Copy link
Contributor

catmando commented Apr 5, 2021

@catmando catmando closed this as completed Apr 5, 2021
ALPHA to production automation moved this from To do to Done Apr 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request performance No effect on functionality, just on memory or speed performance
Projects
Development

No branches or pull requests

3 participants