Add performance improvements in serializeFields function

[mkszepp]

Recently, I started using "tobyz/json-api-server": "1.0.0-rc.1" in an app.

During my first integrations, I checked the performance of JSON responses (without pagination) with larger result sets (1000+ items).

While I know that pagination is the recommended pattern, I still think it could be interesting to improve some performance issues — especially because these optimizations would also benefit users with smaller result sets.

Here are my test results:

Using a list with 3336 data items and one include (which returns 957 included items), the response time is currently around 1.2–1.4 seconds on my development machine. Query execution time is excluded from this measurement (additional SQL-related work is only around ~100ms). This means the total response time is around 1.5 seconds.

On the production server, the same API call takes around 2 seconds with the same dataset.

My conclusion after benchmarking was that the bottleneck is inside this package. So I started investigating possible causes and found the following:

Fix 1

Calling ->withField(...) or ->withInclude(...) clones the full object each time, which adds noticeable overhead.

If this logic is combined into a single function, we can reduce one clone operation per field/include call.

This change improved performance by around ~50–100ms in my tests (not huge, but still something 😅).

Fix 2

In the same area, I noticed an in_array check without $strict = true. This means every comparison uses == instead of ===.

After switching to strict comparisons, I was able to significantly improve performance. In my app, this change reduced response time by around ~500–700ms.

Conclusion

The API response time dropped from ~1.3 seconds to ~750ms — nearly half the original time.

Additional Benchmark

I also tested another API endpoint with 4177 items and 3336 included records.

• Before: ~1.9 seconds
• After: ~1.2 seconds

Question

Is there any way to bring these fixes into the package?

I think Fix 1 should be safe for everyone.

For Fix 2, I’m not completely sure whether switching to strict comparisons could be breaking for some users. As an alternative, I’d also be fine with making strict comparison configurable via an option.

[tobyzerner]

Amazing! Will definitely take a look at these soon. Thanks for your investigation :)