Open vasily-kirichenko opened 6 years ago
The reason for long compile times is that each assignment invokes a macro that compiles and evaluates an Expr[Validate[Char, AnyOf[Digit :: Letter :: Whitespace :: HNil]]]
which is a costly operation. We could try adding a cache for Validate
instances to that macro so that each unique instance is only evaluated once instead of 110 times as in your example.
@fthomas Yes, it sounds good. But it would not solve the problem in general, where you can have hundreds of (different) refined types. What I'm trying to say is that this library should be used with care on large projects.
That caveat only applies if you have lots of static data that you want to check at compile-time. In my projects the vast majority of the validation refined performs happens at runtime (e.g. via circe-refined, doobie-refined, and other integrations) while there are only a handful of literals that are checked at compile-time. And the runtime stuff has not that much impact on compilation time.
In my experience, the compilation time has only been a problem with complicated predicates or with lots of compile-time validations.
@fthomas I was wondering if you knew if it's the macro that takes time, or the implicit resolution of the Validate
instance? I was hoping the changes made to re-organise the Validate
instances in 0.9.0 might have made resolution a good bit faster?
@howyp I've not measured how compilation time changed between 0.8.7 and 0.9.0 due to implicit resolution. That would be interesting to know. What I know is that if the macro is invoked with a Validate
instance that we don't precompute this eval
call is the biggest contributor to compilation time.
First of all, the library is cool and all, but the following code compiles for 24 seconds (!):