[p5.js 2.0 RFC Proposal]: Expand performance profiling

[nickmcintyre]

Increasing access

Profiling performance in a comprehensive and systematic way will help developers to ensure that p5.js is accessible to people in a wide range of circumstances.

Which types of changes would be made?

• [ ] Breaking change (Add-on libraries or sketches will work differently even if their code stays the same.)
• [ ] Systemic change (Many features or contributor workflows will be affected.)
• [X] Overdue change (Modifications will be made that have been desirable for a long time.)
• [ ] Unsure (The community can help to determine the type of change.)

Most appropriate sub-area of p5.js?

• [X] Accessibility
• [ ] Color
• [ ] Core/Environment/Rendering
• [ ] Data
• [ ] DOM
• [ ] Events
• [ ] Image
• [ ] IO
• [ ] Math
• [ ] Typography
• [ ] Utilities
• [ ] WebGL
• [X] Build process
• [X] Unit testing
• [ ] Internationalization
• [ ] Friendly errors
• [ ] Other (specify if possible)

What's the problem?

p5.js currently has no framework in place to profile performance (frame rate and power consumption) across the library or across desktop, laptop, and mobile devices.

As noted in #6776 , The "why" of web performance lays out very plainly how performance impacts accessibility, especially for folks with fewer resources. Optimizing performance would make sketches more accessible to people with modest devices. Doing so would also reduce power consumption while sketches are running.

As @GregStanton so eloquently put it in #6527:

People with less powerful devices (for example, people who can only access the p5.js Web Editor on a mobile phone) may face a variety of barriers. Not being able to run code due to performance would make that list longer. Their devices may also tend to be older, which means they may have trouble holding a charge. So power consumption also has immediate consequences on accessibility, in addition to the global considerations.

Based on the p5.js issue forms, its website, and its contributor docs, p5's literal top priority is accessibility (accessibility actually appears at the top of these documents). As explained above, performance can contribute significantly to this top-line priority.

Side note: Sustainability dovetails nicely with p5.js' core values. I'm trained as an environmental engineer and would love to work on these issues as a steward.

What's the solution?

I propose that we establish a performance baseline using the newly-curated set of example sketches. We could log frame rate and power consumption for each example, then store that data in the repo for analysis.

To get up and running, perhaps we can limit ourselves to using Firefox Profiler on desktop/laptop. We can expand coverage of devices once we have a profiling framework in place. Longer term, I propose re-implementing the examples using other JavaScript libraries to see how we compare to our peers.

Pros (updated based on community comments)

TBD

Cons (updated based on community comments)

TBD

Proposal status

Under review

[AviGawande]

hello @nickmcintyre i didnt get the enough documentation for setting up the project locally , here i had successfully clone the repo but how to proceed in it after. Please provide me some documentation.

[davepagurek]

Having a benchmark would be great!

Beyond the scope of what you're suggesting but related: sometimes there's "low hanging fruit" where we can optimize sketches without any changes to users' code, but sometimes there are tradeoffs we have to make when optimizing performance. One example of this from recent memory is with line rendering in WebGL, where adding stroke caps and joins does slow down rendering, but is also arguably necessary in many cases for visual fidelity, and is quite complex to optimize across all the ways people use it. I'm not sure how many cases we'll find in each category, but we might want to have a stance on what sorts of things we can do in cases like that. A few options are:

• Add new functionality to let users disable features if necessary (possibly even disabling by default)
• Removal of features if we can't feasibly optimize them
• Provide new APIs that allow speedups (e.g. in the case of lines, caching unchanging shapes into p5.Geometry often is a viable solution)
• Acceptance that some features are difficult to run at interactive rates (e.g. updating pixels[]) and documenting them as such

I'm curious where everyone stands on options like that and whether we can decide upon a standard way to deal with these cases in p5.

[nickmcintyre]

Documenting features with a significant performance cost seems helpful. It could be nice to let people explore the tradeoffs in a systematic way. Maybe we err on the side of making tools available and educating.

Should optimizations be addressed at the function level or in a top-level function such as optimize(FES, WEBGL)?

[davepagurek]

I think it might depend on what we think we can do at a high level. Turning off FES is one across-the-board optimization, but beyond that I'm not sure how many optimizations are feasible with no changes to users' code (like caching shapes that don't change and replacing pixels[] modifications with a shader are a bit too complex to do automatically.) So for that reason it might make sense to default to function level choices?

[AviGawande]

thanks alot for your guidance and time.