question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Performance issues for backend use

See original GitHub issue

Hi.

I love the API of yup, and I love it SO much that I’m trying to build an isomorphic application that uses the same yup schema validation in both the frontend and the backend 🚀.

However, at the moment it’s not really viable simply due to the fact that it’s about one order of magnitude slower than it should be, considering what is actually running in the source code (“joi-lite”). I really don’t expect ajv levels of “extreme” performance since yup is not compiling schemas, but I’d expect to at least be somewhere around joi’s level.

First, the setup: https://github.com/JaneJeon/validator-benchmark (I forked https://github.com/icebob/validator-benchmark, updated the dependencies, added strict mode to the yup schema, and properly ran the async validator - I tested synchronous version, and it was literally 2x slower xP)

And, the results (run node .): https://i.imgur.com/AuQLnTD.png

At first, I thought it was because the email/url regex yup was using was ungodly (no offense), so I thought maybe using simplified regex (like here: https://github.com/icebob/fastest-validator/blob/master/lib/rules/email.js) might help.

It didn’t.

I changed the regex in both lib/string.js, es/string.js in node_modules/ and it didn’t affect the performance in any noticeable way.

I messed around with sync vs. async, different ways of running the validation, etc.

Then I realized there’s babel’s crufty code all over the place, in both es/ and lib/. I dug around and found that babel-compiled code often has performance issues, especially regarding ES6 syntaxes.

I suspect that the default babel compilation is what’s slowing down your codebase significantly since, as far as I can tell, you’re only using babel for ESM syntax.

Is there any way you could directly expose the ESM code or at least use a much more efficient compiler/babel setting? People running this in node/backend just need to convert ESM -> CJS. I feel like babel config is key here.

I’d really love to use this in my backend and bring it to production! This is the last thing that’s preventing me.

Thanks

Issue Analytics

  • State:closed
  • Created 3 years ago
  • Reactions:4
  • Comments:28 (11 by maintainers)

github_iconTop GitHub Comments

4reactions
jquensecommented, Oct 21, 2020

gonna try and get something out soon

1reaction
jquensecommented, Nov 24, 2020

not sure what i’m supposed to do with a context-less benchmark @Timer

Gonna guess that you are just running the benchmark from above with the newest version. It’s not an apples to apples comparision, run it while using isValidSync and you get

✔ validator.js                562,183 rps
✔ validate.js                 290,012 rps
✔ validatorjs                 200,192 rps
✔ joi                         168,420 rps
✔ ajv                       7,452,251 rps
✔ mschema                     725,544 rps
✔ fastest-validator         7,541,043 rps
✔ yup                         104,305 rps

   validator.js            -92.55%        (562,183 rps)   (avg: 1μs)
   validate.js             -96.15%        (290,012 rps)   (avg: 3μs)
   validatorjs             -97.35%        (200,192 rps)   (avg: 4μs)
   joi                     -97.77%        (168,420 rps)   (avg: 5μs)
   ajv                      -1.18%      (7,452,251 rps)   (avg: 134ns)
   mschema                 -90.38%        (725,544 rps)   (avg: 1μs)
   fastest-validator            0%      (7,541,043 rps)   (avg: 132ns)
   yup                     -98.62%        (104,305 rps)   (avg: 9μs)
-----------------------------------------------------------------------

This is pretty close to joi, and i’m happy enough with the result. If anyone wants to save off more time please feel free to send a PR

Read more comments on GitHub >

github_iconTop Results From Across the Web

Improve Website Performance- Front-end and Back-end ...
Proven Ways to Improve Website Performance Optimizing Front-end and Back-end · 1. The N+! Query Problem · 2. Database optimization · 3. Server...
Read more >
How to Debug a Slow Service. Investigate and Resolve ...
In this article I will try to write a complete guide on how to investigate and fix performance issues in distributed backend systems....
Read more >
How to fix a slow backend? - Let's talk about Webperf
Very few things can hurt more your backend performances. Here are some tips if you face this problem: reduce their number urgently (internal...
Read more >
Front-End vs. Back-End Performance - Loadster
Back-End Performance Degradation Is Non-Linear​​ The correct answer is C. It might be tempting to say the backend will take the same 400ms ......
Read more >
Web Application Performance: 7 Common Problems and How ...
1) DNS issues and network connectivity · 2) Slow servers and loading time · 3) Poorly written code · 4) Lack of load...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found