Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Categories for AOT, JIT and Dynamic Validation #1126

Open
sinclairzx81 opened this issue Aug 12, 2023 · 5 comments
Open

Categories for AOT, JIT and Dynamic Validation #1126

sinclairzx81 opened this issue Aug 12, 2023 · 5 comments

Comments

@sinclairzx81
Copy link
Contributor

Hi @moltar!

Hey, was wondering if it might be possible to perhaps group the current validators into categories in accordance with how each validator works (this to provide a bit of insight into some of the performance characteristics of each category).

Currently there is quite the divide between fast and slow and not much indication given as to what makes the faster validators fast (or what trade offs are necessary to attain that performance). Also, having a bit of extra info might bring a few insights to developers wanting to have a go at building out a few more high performance options (we could use a few more) :D

All validators generally fall into one of the following 3 categories:

  • AOT - Uses compiler codegen to produce static validation code
  • JIT - Uses runtime codegen to produce code and executes via eval()
  • Dynamic - Uses dynamic property checking

I was thinking perhaps the easiest way to achieve this (from a visual standpoint) might be to add some iconography next to each validator + a legend somewhere giving info as to what each icon means (possibly including the descriptions listed above). Color coded icons might be a good visual indicator too (a contrasting red, green and blue might work quite well)

Just putting the idea out there :)
All the best!
S

@jakebailey
Copy link

I was no joke just about to file an issue like this!

I come back to these benchmarks semi-regularly to explore the state of things (e.g. to pick a lib again, recheck the usability of libs, the works), but I never want a library which requires me to do codegen or build system modification. I'd personally appreciate some sort of labeling or something which at least lets me know which of the validators are using codegen (so, that first category, AOT) so I know what I'm getting into; I honestly forget what each of the different libs do every time I return to these stats 😅.

Splitting the "non-codegen" into eval and non-eval would also probably be helpful for those who can't use eval for various reasons.

@hoeck
Copy link
Collaborator

hoeck commented Aug 13, 2023

  • AOT - Uses compiler codegen to produce static validation code
  • JIT - Uses runtime codegen to produce code and executes via eval()
  • Dynamic - Uses dynamic property checking

I like this classification a lot.

How should we present the results?
Is a simple, additional filter checkbox enough? Or some group-by?
What about a 3-state filter switch: hidden - included - highlighted?

Any ideas / requests?

@moltar
Copy link
Owner

moltar commented Aug 15, 2023

@sinclairzx81 Love your categorization idea! Really clear thinking there. I wanted to do something like that, but couldn't come up with such a clear and concise description as you did.

How about instead of categories, we use a concept of tags. That way anyone can select any arbitrary assortment of tags to compare. And Deepkit can have both tags?

@sinclairzx81
Copy link
Contributor Author

@moltar Hi!

How about instead of categories, we use a concept of tags. That way anyone can select any arbitrary assortment of tags to compare. And Deepkit can have both tags?

This would be perfect! :)

@Lyumih
Copy link

Lyumih commented Sep 12, 2023

Great idea!
I want to suggest the following.
Make icons AOT, JIT, Dynamic links.
Clicking on the icon will open a link with a description of what AOT, JIT, Dynamic is.
Unfortunately, I do not know how they differ. But the speed varies at times.
And yup, which we have been working on for many years, is almost in last place

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants