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

Performance improvement ideas for Zinc 1.4.x #933

Closed
retronym opened this issue Oct 16, 2020 · 0 comments · Fixed by #939
Closed

Performance improvement ideas for Zinc 1.4.x #933

retronym opened this issue Oct 16, 2020 · 0 comments · Fixed by #939
Assignees

Comments

@retronym
Copy link
Member

retronym commented Oct 16, 2020

I'm profiling a build using the latest Zinc. I'll use this ticket to record the areas where Zinc could be improved.

JarUtils.ClassInJar

The build is using straight-to-JAR compilation. This seems to be an allocation hotspot within:

   jo2o(output.getSingleOutputAsPath) match {
      case Some(so) if so.getFileName.toString.endsWith(".jar") =>
        knownProducts foreach { product =>
          new JarUtils.ClassInJar(product.id).toClassFilePath foreach { path =>
            ps.add(path.replace('\\', '/'))
          }
        }

The main optimization would be to avoid repeatedly calling new File in ClassInJar.splitJarReference on what I presume is always the same path (the path of the JAR), and is anyway discarded by def toClassFilePath: Option[ClassFilePath] = splitJarReference._2!

new File internally incurs String allocations, at least on Windows, in WinNTFileSystem.normalize.

I am also inclined to remove use of parallel collections should be used in knownProducts.

This is also inefficient:

val Array(jar, cls) = toString.split("!")
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant