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

Extremely slow compilation when silencer plugin enabled #45

Closed
payurgin opened this issue Feb 20, 2020 · 6 comments
Closed

Extremely slow compilation when silencer plugin enabled #45

payurgin opened this issue Feb 20, 2020 · 6 comments

Comments

@payurgin
Copy link

Next lines of code compiles at least 25 seconds when silencer plugin enabled and just 1 seconds with disabled plugin

import sttp.tapir._

case class Foo(a: Int)

object Main extends App {
  val a = implicitly[Schema[Foo]]
    .modify(_.a)(_.description("foo")) // 1s with silencer and 1s without
    .modify(_.a)(_.description("foo")) // 1s with silencer and 1s without
    .modify(_.a)(_.description("foo")) // 1s with silencer and 1s without
    .modify(_.a)(_.description("foo")) // 1s with silencer and 1s without
    .modify(_.a)(_.description("foo")) // 1s with silencer and 1s without
    .modify(_.a)(_.description("foo")) // 1s with silencer and 1s without
    .modify(_.a)(_.description("foo")) // 1s with silencer and 1s without
    .modify(_.a)(_.description("foo")) // 1s with silencer and 1s without
    .modify(_.a)(_.description("foo")) // 1s with silencer and 1s without
    .modify(_.a)(_.description("foo")) // 1s with silencer and 1s without
    .modify(_.a)(_.description("foo")) // 2s with silencer and 1s without
    .modify(_.a)(_.description("foo")) // 6s with silencer and 1s without
    .modify(_.a)(_.description("foo")) // 16s with silencer and 1s without
    .modify(_.a)(_.description("foo")) // 25s with silencer and 1s without
}

where modify - is macro function from tapir library.

Repo with simple reproducer: https://github.com/igrocki/slow-silencer-tapir

I found ugly workaround: breaking method chain into two or more chains like:

val a = implicitly[Schema[Foo]]
    .modify(_.a)(_.description("foo")) 
    .modify(_.a)(_.description("foo")) 
    .modify(_.a)(_.description("foo")) 
    .modify(_.a)(_.description("foo")) 
    .modify(_.a)(_.description("foo")) 
    .modify(_.a)(_.description("foo")) 

val b = a.modify(_.a)(_.description("foo"))
    .modify(_.a)(_.description("foo")) 
    .modify(_.a)(_.description("foo")) 
    .modify(_.a)(_.description("foo")) 
    .modify(_.a)(_.description("foo")) 
    .modify(_.a)(_.description("foo")) 
    .modify(_.a)(_.description("foo")) 
    .modify(_.a)(_.description("foo")) 
@SethTisue
Copy link
Contributor

very nice catch!! 👏 thank you for isolating and reporting

@SethTisue
Copy link
Contributor

SethTisue commented Feb 20, 2020

fwiw, scala/scala#8373 doesn't seem to have this problem (tested with 2.13.2-bin-59cf05f-SNAPSHOT). I wonder what @lrytz did differently. (of course, it's easier to avoid extra traversals and such when something is integrated into the compiler directly, so perhaps there's no mystery.)

@ghik
Copy link
Owner

ghik commented Feb 21, 2020

This is caused by tapir's macros which seem to blow up exponentially. Silencer looks for @silent annotations in both macro expandees and macro expansions. In the reproduction provided by @igrocki (huge thanks!) silencer has to traverse 1659690482(!) trees. But when I disabled looking for @silent annotation in macro expansions, it drastically went down to just 569 trees and compilation time dropped accordingly.

I probably could just ignore macro expansions as it's very unlikely that someone would put @silent annotations in macro generated code, but I'm not sure if it won't break something.

@ghik
Copy link
Owner

ghik commented Feb 21, 2020

Ok, I've decided to go on and ignore macro expansions by default. I've also introduced an option to bring back the old behaviour (-P:silencer:searchMacroExpansions).
These changes are available in freshly released 1.6.0

@ghik ghik closed this as completed Feb 21, 2020
@SethTisue
Copy link
Contributor

This is caused by tapir's macros which seem to blow up exponentially

I wonder if tapir's maintainers know about that.

@adamw
Copy link

adamw commented Feb 27, 2020

@SethTisue yes :) softwaremill/tapir#455

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

4 participants