[pickers] Improve open action performance

[oliviertassinari]

Why it matters

Opening the date picker on desktop and mobile have a perceptible delay, it's even more noticeable with the range picker. As a UI library, we have a 100ms delay budget before the users start to notice.

0 to 100ms | Respond to user actions within this time window and users feel like the result is immediate. Any longer and the connection between action and reaction is broken.

• https://developers.google.com/web/fundamentals/performance/rail

0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.

• https://www.nngroup.com/articles/response-times-3-important-limits/

The problem

On this demo https://mui.com/x/react-date-pickers/date-picker/#basic-usage, the pickers take about 227ms to show with an x4 throttle (to simulate a regular Windows laptop). The lag can be felt.

Compared with these, they two also have the advantage of triggering on mouse-down which saves ~80ms

• https://reactdatepicker.com/: 56ms

• https://ui.shadcn.com/docs/components/calendar: 164ms

• https://retool.com/components/date 165ms

• https://vercel.com/design/calendar: 192ms

I suspect that part of the root cause is that we use too many Material UI primitives (not fast enough), we could instead style from the theme directly.

2020 exploration on the problem

Regarding delivering on better runtime performance

1. The first thing I would look at is the usage of the ButtonBase for the days, I suspect an easy win by replacing them with a simple <button>, it seems to be an obvious win, we don't need the ripple there.

For instance, in dev mode, we get from 400ms to 250ms with this diff:

diff --git a/lib/src/DateRangePicker/DateRangePickerDay.tsx b/lib/src/DateRangePicker/DateRangePickerDay.tsx
index 9f54cb31..05ea0182 100644
--- a/lib/src/DateRangePicker/DateRangePickerDay.tsx
+++ b/lib/src/DateRangePicker/DateRangePickerDay.tsx
@@ -135,13 +135,7 @@ export const PureDateRangeDay = ({
           [classes.rangeIntervalDayPreviewStart]: isStartOfPreviewing || isStartOfMonth,
         })}
       >
-        <Day
-          allowKeyboardControl={false}
-          disableMargin
-          {...other}
-          day={day}
-          selected={selected}
-          inCurrentMonth={inCurrentMonth}
+        <button
           data-mui-test="DateRangeDay"
           className={clsx(
             classes.day,
@@ -152,7 +146,9 @@ export const PureDateRangeDay = ({
             },
             className
           )}
-        />
+        >
+          1
+        </button>
       </div>
     </div>
   );

2. The second thing I would look at is how "loaded" the DOM is. For instance, react-day-picker has a single DOM node per cell vs x for us. replacing div > div > button with button we reduce the runtime from 250ms to 220ms.

I believe we could do the same with the year picker. div > h6 seems wasteful (as well as breaking the accessibility rule of headers continuity. It should be div > div at the very least, and ideally only div.

3. Removing the Grow animation gets us down from 220ms to 130ms, still in dev mode. Something seems wrong with the implementation, it double renders. In this condition, I think there we are better off without. We would need to investigate, on what's wrong. We might only need a memo on the component just below Grow. Hopefully, we will be able to make the other components benefit from it.
4. I haven't noticed another opportunity but it's probably not necessary to look deeper. from 400ms to 130ms in dev mode, if we extrapolate to the 190ms baseline, it means 62ms in production. This is perfect.

Environment

v6.11.1

[eps1lon]

I haven't noticed another opportunity but it's probably not necessary to look deeper. from 400ms to 130ms in dev mode, if we extrapolate to the 190ms baseline, it means 62ms in production.

Just in case others are reading this: Do not extrapolate from dev to prod. And in general: Do not meassure in development.

On my high-end $3,000 MacBook,

These are not expensive because of their performance.

Current results for opening a picker by keypress:
Datepicker: 50ms
Timepicker: 30ms
DateRangePicker: 70ms

We can definitely improve the performance and there are some "easy" wins within reach. But let's be accurate in our measurements so that we can make lasting changes. Not measuring did lead to some unnecessary work.

[flaviendelangle]

This issue is very old and did not get a lot of feedback.
I think we can start by doing a small performance analysis of the pickers in there current shape to see if we find bottlenecks.

[LukasTy]

Need to refresh the current condition of pickers' performance before identifying if any work is still needed.

[oliviertassinari]

I have refreshed the content, extracting what I had identified in #7440. Part of the frustration is around the animation, which is a bit slow. I touched a bit on it in #10006.