Make cron validate x100 faster #306
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
this commit is a preparation of the introduction of a cache mechanism to speed up the execution of cron-validate. Although the commit looks irrelevant if considered in isolation, it greatly simplify the analysis of the next commit. I also removed unused imports from index.ts Signed-off-by: albertodiazdorado <[email protected]>
In the previous source code version we would load the built-in presets on every invocation of 'cron' (via 'validateOptions'). This means that we do a lot of repeated work on consecutive invocations of 'cron'. With the new design we load the presets just once when we load the module 'options.ts', via the new function 'loadPresets()'. In order to avoid circular dependencies, I modified 'presets.ts' to export just vanilla JavaScript objects. Signed-off-by: albertodiazdorado <[email protected]>
cron-validated was very slow when called in a loop. The reason is that we repeated all these operations in every call: 1. Merge the preset and the overrides into a so-called 'unvalidatedConfig' 2. Dynamically generate a yup validation schema from the preset and the override 3. Validate the 'unvalidatedConfig' using the dynamically generated schema Step 2 is particularly slow, but steps 1 and 3 aren't particularly fast either. Luckily for us, all these 3 steps are perfectly cacheable. This Pull Request introduces a so-called 'optionsCache' to avoid repeating the 3 steps if we already executed them in the past (which happens all the time in a loop). The cache is a map from 'cache keys' to 'validated options'. The cache key is the concatenarion of 'presetId' and a stringified 'override' object. If two function calls produce the same cache key, it invariably means that the user wants to use the same 'Options' in both function calls. This is how the cache produces a performance improvement of about x100 for consecutive calls. Note that the construction of the cache key is not optimized. If the user uses 'cron-validate' two consecutive times with identical 'override' objects, but swaps the order of the override object fields, then they will not benefit from caching. This can be fixed by using deterministic stringification, but I do not consider it necessary. Signed-off-by: albertodiazdorado <[email protected]>
This was referenced Dec 20, 2024
|
Hi @Airfooox , do you think you could have a look into this? |
|
Yea, I'll take a look at this this week or the next. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This Pull Request addresses #81
Foreword
I believe that this Pull Request contains the right ideas to make
cron-validateperform reasonably fast. However, I am not sure if my implementation aligns with your designs idea @AirfoooxThus, please let me know if you disagree with the implementation and we can try to find a better means to integrate the performance improvements into the library.
Description
This Pull Request introduces two small optimizations that makes
cron-validatex100 faster when called in a loop. The changes are:options") instead of when callingvalidateOptions. Since the build-in presents do not change, we can load them just once instead of loading them every time that we usecron()cron()with the same settings multiple time (defined by preset/presetId and overrides), then we would spend quite a lot of time creating and validating anOptionsobject. The creation & validation of this object makes the library about x100 faster when called in a loop.Benchmarking
I used this script for benchmarking, using some cron expressions akin to the ones I have been dealing with in production:
To execute the benchmark, first you need to delete the line
"type":"module"frompackage.json. The output produced by the compiler is CJS, so we cannot import it successfully if we mark the package as ESM. Then, execute the following:git checkout $branch npm run build node profile.mjsOn my machine, these are the results for
next:These are the results for
make-cron-validate-x100-faster: