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

investigate ways to reduce bundle size #4817

Open
gvwilson opened this issue Oct 22, 2024 · 2 comments
Open

investigate ways to reduce bundle size #4817

gvwilson opened this issue Oct 22, 2024 · 2 comments
Labels
feature something new P2 considered for next cycle performance something is slow

Comments

@gvwilson
Copy link
Contributor

gvwilson commented Oct 22, 2024

The plotly.py bundle is approx. 19 Mbyte, which will be a problem for WASM deploys. We should investigate ways to reduce its size.

cf plotly/dash#3050 and #3294

@gvwilson gvwilson added feature something new P2 considered for next cycle performance something is slow labels Oct 22, 2024
@alexcjohnson
Copy link
Collaborator

There are some obvious but fairly small things we could do here:

  • get rid of remaining sys.version_info < (3, 7) (can't get rid of the conditional because we want type checking to have that path, but we can get rid of the version check)
  • get rid of _plotly_future_ and the stub modules that reference it just to throw an error. We've been in this future for plenty long.
  • get rid of unnecessary comments in generated code ... ... ... ...
  • Some attribute descriptions are absurdly long, like do we really need to list all the CSS named colors in the docstring for every color? Wouldn't it be a better UX to link to that list at some URL? Similarly fonts no longer need the whole list of what fonts are supported on Chart Studio Cloud.

The bigger thing will be to reduce duplication by subclassing attributes rather than repeating the same definition a million times. Like there are only a few flavors of font attributes - whether they support arrays or not, maybe which sub-attributes they support? Also for error handling seems there are different base classes for traces and layout, but it's still a small list. If we could detect which flavor we have and inherit from a base class the definition should in principle be as simple as:

for single-valued layout fonts like Layout.Font:

from plotly.basedatatypes import BaseLayoutFont as _BaseLayoutFont

class Font(_BaseLayoutFont):
    _parent_path_str = "layout.title"
    _path_str = "layout.title.font"

and for a trace font that supports arrays, like Bar.TextFont:

from plotly.basedatatypes import BaseTraceArrayFont as _BaseTraceArrayFont

class TextFont(_BaseTraceArrayFont):
    _parent_path_str = "bar"
    _path_str = "bar.textfont"

Finally, I wonder if we can get rid of all the explicit *src properties? These only useful to Chart Studio users, and even then I suspect barely anyone uses them. We probably don't want to remove this support entirely, but I wonder if we can just handle them in __setattr__/__getattr__ so they continue to function, without all the extra overhead of explicitly defining them?

@acepace
Copy link

acepace commented Dec 21, 2024

I'm going to check about turning all the generated code into a zip file (at setup stage or before) and using zipimport. Then the unnecessary comments are not really interesting and mostly get comrpessed away.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature something new P2 considered for next cycle performance something is slow
Projects
None yet
Development

No branches or pull requests

3 participants