#28055: Staticfiles HashedFilesMixin postprocess optimization
-------------------------------------+-------------------------------------
     Reporter:  Konrad Lisiczyński   |                    Owner:  Konrad
         Type:                       |  Lisiczyński
  Cleanup/optimization               |                   Status:  assigned
    Component:  contrib.staticfiles  |                  Version:  1.11
     Severity:  Normal               |               Resolution:
     Keywords:  staticfiles          |             Triage Stage:
  HashedFilesMixin post_process      |  Unreviewed
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------

Comment (by David Sanders):

 > Maybe we could contact the author of this code so he or she could
 provide us some insight why it was done this way and is it possible to
 optimize it somehow.

 I am the original author of some of the code (the patch that refactored
 the code you mentioned), it's just been a while and some details have
 slipped, and I don't have time to get back into it deeply.

 Looking at it a tiny bit more, though, I think line 304 is necessary, and
 to make this more clear it should be using `old_hashed_name` for the
 `_save` call instead of `hashed_name`. It is saving the file content with
 the old hashed name before recalculating the new hash on the (potentially)
 changed content.

 The test failures you saw when removing it are due to the fact that
 `CachedStaticFilesStorage` relies on these intermediate files for proper
 behavior. The alternative would be for `CachedStaticFilesStorage` to
 recalculate all hashes on a single cache miss, which is very not good.
 With the intermediate files it can re-calculate the hash for a single file
 with a few file accesses.

 If the concern is using a storage backend like S3, maybe a final upload
 step could be refactored in? The `collectstatic` process is never going to
 be very efficient if it's writing and reading directly to S3. The post-
 processing requires lots of file reads and writes, so remote storage isn't
 great for that.

--
Ticket URL: <https://code.djangoproject.com/ticket/28055#comment:8>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.0ee57d10fb6ee5660a480cd80f3deea9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to