◄ ► | Edit | Home | Admin | en de fr et | Sign in

#6167 (Should we cache delayed values?)

40 · by Luc Saffre · in Developers · assigned to Sharif Mehedi

Summary

The detail of a school.Groups in Lino Prima takes a tangible amount of time on our production site. How can we optimize this?


Answer: using the delayedhtmlbox decorator.


We tried by making the HTML display mode to be always delayed (see DELAYED_HTML in lino.core.elems) and

it worked as such, but it caused --or revealed-- some strange test failures. The root cause of the evil seems to be the fact that LightWeightContainer creates a new virtualfield when it is actually too late for creating new data elements.... The true solution might be that Actor.get_data_elem(), when it detects a slave actor, should not return that actor's class object but wrap it into the htmlbox that is currently created in LightWeightContainer. But this is a bigger story, right now the delayedhtmlbox decorator is fine.

Children

Comments

  • 1 year, 3 months ago by Luc Saffre about #6167 (Should we cache delayed values?) (1 reply) : I will release this now to the prima prod sites (pdg and primademo on pilv) .
  • 1 year, 3 months ago by Luc Saffre about #6167 (Should we cache delayed values?) : I reverted my lino repo to before @8lurry's and started the test suite. If these problems really came by this relatively small change, I'll revert it and try to implement these heavy views in Prima using an explicit delayedhtmlpanel. And if that works, we leave the circular data/layout element creation iss...
  • 1 year, 3 months ago by Luc Saffre about #6167 (Should we cache delayed values?) : I discovered that we have a decorator "delayedhtmlbox", which creates a field DelayedHtmlBox. I could have used this instead of asking to make the html display mode delayed.
  • 1 year, 3 months ago by Luc Saffre about #6167 (Should we cache delayed values?) : Idea: the true solution might be that Actor.get_data_elem(), when it detects a slave actor, should not return that actor's class object but wrap it into the htmlbox that is currently created in LightWeightContainer.
  • 1 year, 3 months ago by Luc Saffre about #6167 (Should we cache delayed values?) : After a day of poking around I can tell you that this is a tough one...
  • 1 year, 3 months ago by Luc Saffre about #6167 (Should we cache delayed values?) : The When Lino starts up page does not mention layout elements right now. But it should.
  • 1 year, 3 months ago by Luc Saffre about #6167 (Should we cache delayed values?) : The fundamental problem is that LightWeightContainer.__init__() creates a VirtualField, which it adds to the lh.layout._datasource. That's kind of forbidden in Lino. All data elements (database fields, virtual fields, actors, actions...) are assumed to exist when the kernel starts creating layout el...
  • 1 year, 3 months ago by Luc Saffre about #6167 (Should we cache delayed values?) : The problem is visible e.g. with "python manage.py test tests.test_notify" in noi1r.
  • 1 year, 3 months ago by Sharif Mehedi about #6167 (Should we cache delayed values?) : I published my changes on lino and react.
  • 1 year, 3 months ago by Sharif Mehedi about #6167 (Should we cache delayed values?) : Through the getmro, the get_data_elem were returning a VirtualField and create_atomizer was creating a StoreField for it. But now that we removed the getmro stuff, data element for slave panels are now subclasses of actors.Actor. And create_atomizer stops here.
  • 1 year, 3 months ago by Luc Saffre about #6167 (Should we cache delayed values?) : Together we removed the "for cls in getmro(self):" in Actor.get_data_elem(), which fixed the issue in lets1.rst but caused #5739 (Oops, get_atomizer(...) returned None) to reappear...
  • 1 year, 4 months ago by Sharif Mehedi about #6167 (Should we cache delayed values?) : @luc I have some broken test cases that I should show you.
  • 1 year, 4 months ago by Sharif Mehedi about #6167 (Should we cache delayed values?) : Now all the slave actors with DISPLAY_MODE_HTML are delayed.
  • 1 year, 4 months ago by Luc Saffre about #6167 (Should we cache delayed values?) : Yes, the PupilsAndProjectsByGroup slave panel is not using delayed values, I guess that's because it is in summary view. So we probably don't need no caching, we just need to make slave panels use delayed_value also when it's in summary mode. @8lurry is that a quick win?
  • 1 year, 4 months ago by Luc Saffre about #6167 (Should we cache delayed values?) : I increased the priority because they will complain about slowness if we don't find a solution.
  • 1 year, 4 months ago by Luc Saffre about #6167 (Should we cache delayed values?) : Maybe the projects/PupilsAndProjectsByGroup slave table in the school.MyGroup detail is not a delayed value? Because it is in html or summary view.
  • 1 year, 4 months ago by Luc Saffre about #6167 (Should we cache delayed values?) : My spontaneous idea is that Lino could simply cache the result of a delayed_value per user_type. But experience shows that caching is never simple. The app developer needs a way to invalidate the cache. And the ⎚ button should also clean the cache on the server-side.
  • 1 year, 4 months ago by Luc Saffre about #6167 (Should we cache delayed values?) : Created new Ticket #6167 (Should we cache delayed values?).