perf(jsx/dom): improve performance

[usualoma]

#3264

Key changes

use for-loop instead of recursion for findInsertBefore 0dadfbc

As @ryuapp pointed out in #3203, the implementation with recursive calls did not perform well and sometimes resulted in errors when there were a large number of elements, so it was modified so that recursive calls were not made.

assign type and ref to node object directly. Object.defineProperties is too slow 7fd73ef

• reactElement.type
• reactElement.ref

https://github.com/honojs/hono/compare/main...usualoma:hono:perf/jsx-dom?expand=1#diff-c9b14c1b74662b399c25e6dc0c870408c466e1c96e39a1d429903b2a3d0db51fL11-L20

The code to make the following properties referential is for React compatibility, but the implementation using Object.defineProperties was very expensive. This change is not pretty, but it is an acceptable redundancy when considered as a trade-off for improved performance.

Reduce recalculation and reapplication when properties are unchanged

In some cases, DOM attributes were being reassigned even when there were no changes to the properties, so reassignment is no longer performed when it is unnecessary.

benchmark

Based on this branch (thank you very much @aminya!),

https://github.com/aminya/js-framework-benchmark/tree/hono

The following changes were added and benchmarked in my environment.

diff --git a/frameworks/keyed/hono/src/index.tsx b/frameworks/keyed/hono/src/index.tsx
index 2628e205..998c4b0f 100644
--- a/frameworks/keyed/hono/src/index.tsx
+++ b/frameworks/keyed/hono/src/index.tsx
@@ -141,9 +141,8 @@ const App = () => {
     <table class="table table-hover table-striped test-data">
       <tbody>
         {data.map(item => {
-          console.log(item);
           return (
-            <Row item={item} selected={selected === item.id} dispatch={dispatch} />
+            <Row key={item.id} item={item} selected={selected === item.id} dispatch={dispatch} />
           );
         })}
       </tbody>

Performance for creation or update is roughly equivalent to React, with smaller file sizes and memory usage, which is an expected result since "hono/jsx" aims for "an implementation with a React-compatible API that is small enough to be practical with a small amount of code".

The author should do the following, if applicable

• Add tests
  • Only a few tests have been added, but as most of the changes are internal refactoring with no external specification changes, no further additional tests are considered necessary.
• Run tests
• bun run format:fix && bun run lint:fix to format the code

[usualoma]

@yusukebe Would you please review?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.31%. Comparing base (e6459e7) to head (9d6e16e).
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3288      +/-   ##
==========================================
+ Coverage   96.24%   96.31%   +0.07%     
==========================================
  Files         151      151              
  Lines       15293    15368      +75     
  Branches     2662     2700      +38     
==========================================
+ Hits        14718    14801      +83     
+ Misses        575      567       -8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[usualoma]

Minor refactorings and tests are added.
There is no change in behavior, but test coverage scores have improved.

[yusukebe]

@usualoma

Thanks. I'll review this.

[yusukebe]

LGTM!

[yusukebe]

@usualoma

Looks good to me!

Performance for creation or update is roughly equivalent to React, with smaller file sizes and memory usage, which is an expected result since "hono/jsx" aims for "an implementation with a React-compatible API that is small enough to be practical with a small amount of code".

Yes. You are right. In my environment, the scores were Preact, hono/jsx, and React in order of speed, but similar to yours. This score is reasonable. For example, optimizing the building step to minify build code size efficiently may be possible, but we don't have to do it since it would only be a small improvement.

Anyway, thank you for the awesome improvement!

[aminya]

Based on this branch (thank you very much @aminya!),

You're welcome! It's nice to see that the benchmark effort resulted in these improvements. I'll update the benchmark based on the new version.