Skip to content

Improve ReactPy Performance #557

Description

@Archmonger

Proposed Changes

Find the hot spots in ReactPy's code-base in order to identify where attention should be focused. Once we know this, we will be able to focus our efforts on performance improvements.

Implementation Details

Analysis

Use Yappi to profile ReactPy dispatchers and determine what is taking the most significant amounts of time.

We will also need to figure out how to test websocket concurrency. It seems like there are very few tools for this, especially for our applications. We're probably going to have to create out own benchmarking tools. Here's some resources we might want to read through later.

Sync and Async

Currently, ReactPy relies on synchronous code to properly queue renders. Sync code is known to blocks the asyncio event loop, which causes concurrency issues.

See section "Two Worlds of Python" for why this is a problem:
https://arunrocks.com/a-guide-to-asgi-in-django-30-and-its-performance/

All synchronous functions should be converted to async within ReactPy core. They could alternatively be threadpooled. See reactive-python/reactpy-django#31 for the original discussion on this.

Extreme Countermeasures

If optimizations can't be suitably performed within Python, consider writing C/C++ code exposed via Python APIs that performs the same functionality as the non-performant parts of IDOM.

Activity

  1. Archmonger commented on Dec 26, 2021

    @Archmonger
    ContributorAuthor

    A quick test of using pyjion.enable() within dispatch_single_view has shown performance degradation, likely due to the async with limitations noted in their documentation.

  2. rmorshea commented on Dec 26, 2021

    @rmorshea
    Collaborator

    There's definitely a lot of room for improvement. The areas to focus on, probably in this order, are:

    1. Computing JSON patches. Right now this is using a pure Python library that I've come to notice isn't very actively maintained.
    2. Find and optimize the hotspots in rendering VDOM models (see idom/core/layout.py).
    3. Server-side rendering (i.e. serve the initial view as static HTML).
  3. Archmonger commented on Dec 27, 2021

    @Archmonger
    ContributorAuthor

    JSON Patch

    I tried doing some research, seems like there isn't anything else worthwhile on the python side. This is a promising variant on NPM.

    This raises a question of whether it's worth the performance to compute a JSON Patch in Python as opposed to resending the whole JSON content body (and calculating the patch client sided).

    Internal Layout

    Just during my digging I've already seen a couple of situations that could be migrated to list comprehension, which is significantly faster than python loops.

    SEO Compatible SSR

    Implementing SSR is definitely going to complicate IDOM core. SSR may actually reduce IDOM performance. Everything happening on the client side isn't blocking the WS queue.

    This is a big topic to tackle and deserves a discussion on its own.

    I'm not even sure where I'd say we add this to the roadmap. Priority of this card depends on long term goals and focus. I'd personally rank it pretty low on the list.

    Roadmap

    I'd like to work with you on fillling out GH Projects to provide visibility on version goals.

    We should also tag up to discuss OSS funding. IDOM is definitely something that I'd be able to pitch.

  4. rmorshea commented on Dec 27, 2021

    @rmorshea
    Collaborator

    Yeah, scrap what I said before, we need to profile before doing any work. It's very possible that using JSON patch doesn't provide any significant benefit in the most common use cases.

    To the roadmap, yes let's find a time to coordinate that. There's actually a roadmap page in the docs I haven't update in a while.

    And for funding, I suppose the question is what it would be for. I'm happy to get reimbursed for the time I already put in, but I don't have more to give, so adding money won't make things go faster. It would be more valuable to find a way to encourage outside contributions, either from yourself or others.

  5. Archmonger commented on Jan 2, 2022

    @Archmonger
    ContributorAuthor

    See reactive-python/reactpy-django#31 for a relevant performance issue that will eventually need to be resolved.

    I believe it's going to be incredibly important for IDOM to support async components. In the case of Django, users will experience WS performance degradation due to blocking the websocket event loop.

  6. added this to the milestone on Jan 11, 2022
  7. added
    priority-3-lowMay be resolved one any timeline.
    type-investigationAbout research and gathering information
    and removed on Jan 13, 2022
  8. changed the title [-]Improve Layout Rendering Performance[/-] [+]Improve IDOM Performance[/+] on Jan 31, 2022
  9. modified the milestones: , on Jan 29, 2023
  10. removed this from the milestone on Feb 21, 2023
  11. changed the title [-]Improve IDOM Performance[/-] [+]Improve ReactPy Performance[/+] on Jun 22, 2023
  12. Archmonger commented on Jul 10, 2023

    @Archmonger
    ContributorAuthor

    We might get some performance benefit by pushing ReactPy into it's own dedicated backhaul thread (containing an asyncio loop). One thread per ASGI worker, which we can initialize within reactpy:__init__.py.

    That way, rendering components won't prevent the webserver from doing webserver things.

  13. linked a pull request that will close this issueConcurrent Renders #1165on Nov 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    priority-3-lowMay be resolved one any timeline.type-investigationAbout research and gathering information

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions