Transformer Performance about typescript-is HOT 4 CLOSED

Hi @danielbodart

Thanks for the info. To be honest I haven't looked at performance at all. It is expected that using the transformer will increase the compile time by some amount, because the entire AST has to be visited (I don't think there are any TypeScript APIs that allow indexed queries on the AST.) There are probably some small optimizations that can be made here and there, but I don't know if they will have a great impact on performance. Analytically the transformer should be linear in the size of your code + the number of calls you make to is, assertType, etc. and the size of the types in those calls.

Also, I don't know how much of the performance is due to ttypescript either, but I can't imagine that being a bottleneck.

If you have any ideas on improving performance, feel free to share.

from typescript-is.

I did some more testing and just enabling ttsc with no plugins adds about a 7% slow down!. Adding a simple plugin that just console.log adds another 2% (as consoles are synchronised that's probably not helping)

I had a look at how ttypescript monkey patches tsc and it's pretty simple but I wonder if tsc is using some form of parallelism (which is pretty standard practice in compilers) that is being affected by sharing the plugins object and causing some kind of synchronisation under the hood.

If this was my library I'd probably only support is<T> on interfaces that were also decorated with an annotation, this way I could generate a type guard implementation only for interfaces that op-in and then make is<T> error if it didn't find the generated method at runtime. This would mean I would only have to walk the annotations in the AST on interfaces and ignore all the rest of the source code (which would also be a lot less work for me)

I'm not suggesting you change your library just outlining how I might do this, as this is the strategy I've used in other languages.

from typescript-is.

Nice analysis. Pretty surprising that a simple console.log plugin would add 2%+7% compile time.

Regarding the annotation idea:

• You'd still have to walk the AST to find the annotations, unless there is a TypeScript compiler API that can be queried for all annotations, but I'm not aware of such an API. So in terms of time saved for walking the AST I don't think it would make much of a difference.
• It is possible to emit the type guard function for a specific type only once; currently it is done per call to is<T>. This would save on the amount of time taken to generate the type guards. This is very much related to https://github.com/woutervh-/typescript-is/issues/7
• I would like to keep it as simple as possible for the users to make use of the library, so forcing them to add annotations and enable the decorators flag in the tsconfig is yet another step they would need to take.

It's also possible to cache already seen types. It would speed up compile time significantly if the same type is checked in multiple places in the code. Again, it's related to the other issue, because in that case it would have to be cached by default already.

Anyway I think https://github.com/woutervh-/typescript-is/issues/7 is the way forward when it comes to speeding up compilation and reducing emitted code size.

from typescript-is.

I'll close this ticket for house keeping reasons.

from typescript-is.