Admin dashboard slows down significantly after rendering large array

svn__2 years ago

16

• 

  jmikrut

  2 years ago

  so we have done some significant performance optimizations to be able to handle thousands of fields rendered at once, but it seems like you are hitting the upper limit of what is possible to render

• 

  notchr2 years ago

  Does this boil down to a limitation of the DOM? Could a virtual list component be a solution?

• 

  jmikrut

  2 years ago

  well, honestly yes

  
  
  

  but if he has 13 fields per 200 rows, that's 2600 field components

  
  
  

  that will melt any React app

• 

  notchr2 years ago

  Ah that's true

  
  
  

  Especially if the fields types are all varying

• 

  jmikrut

  2 years ago

  i will say that we do lots of fancy stuff, like

  not

  render the fields unless they are within 2000 px of the viewport

  
  
  

  so this should optimize a lot of that

  
  
  @545926768327131137

  if you can create a minimally reproducible repo, we would be happy to look into this, because there is a chance that our performance enhancements are just not working for some reason

  
  
  

  although if possible, you may want to just try and reimagine your content model in general - maybe have each array row render a single relationship field, where the editing of each row is done in the "drawer" UI instead

• 

  svn__2 years ago

  I'm afraid they are working correctly, I've already noticed this when scrolling. I'll prepare a repo with reproduction for you, just give me a few minutes. I'll also try to reimagine model for this collection before going with a custom field

• 

  jmikrut

  2 years ago

  it may also be because of how many conditions you have

• 

  notchr2 years ago

  That may be the best approach, modify the data structure first if possible

• 

  jmikrut

  2 years ago

  in the future, we want to create an alternate, higher-performance conditions workflow where you can subscribe only to the fields that you want to "watch" for changes

  
  
  

  if you have lots of conditions, that could be the reason why your performance is suffering

• 

  notchr2 years ago

  I keep meaning to check out:

  https://developer.mozilla.org/en-US/docs/Web/CSS/content-visibility

  , and other draw-related CSS optimizations. Though, this may be specifically the amount of nodes

• 

  jmikrut

  2 years ago

  i think it's probably related to react rerendering so many things

  
  
  

  not the draw performance itself

• 

  notchr2 years ago

  Ahhh

• 

  svn__2 years ago

  Yep, I think so too

  
  
  

  and it probably won't be a problem with a custom field that renders the whole list as paragraphs and has just

  edit

  button for each entry

  
  
  

  In terms of conditions, I've commented them out and prepared a very simple reproduction. Just need to create a repo for this, will come back with the link soon

• 

  jmikrut

  2 years ago

  beautiful

  
  
  

  thank you!

• 

  svn__2 years ago

  here is the link to reproduction:

  https://github.com/svntime/payload-large-array

  (based on reproduction-guide from Payload's repo so

  yarn dev _community

  should be enough)

  
  
  

  it's simplified and doesn't work that bad but mine collection config is a bit more complex 😄 I want to build a "report" from the race - each rider has multiple scores and relationship field to Riders collection

  
  
  

  and it works like on the repo above with 4x CPU slowdown from devtools

  
  
  

  scrolling the list is fast but when you try to open the row or save the changes, it takes some time

  
  
  

  and as mentioned before, it's a lot to calculate for CPU and I understand why it works like that

  
  
  

  I'll try to reimagine the model or just build a simple renderer component for the array (with edit form as a modal for each row)

  
  
  

  Forgot to mark this one as answered. Things got better after upgrading to 1.10.1 and as I saw in the comments here:

  https://github.com/payloadcms/payload/issues/2747

  , it may get even better in the future. Great job guys and thanks!

• 

  jmikrut

  2 years ago

  woah, nice!

  
  
  

  thanks for the update

  @545926768327131137