为什么Scala的图书馆的大小在2.7和2.8之间是两倍？

发布时间：2020-12-16 09:45:41 所属栏目：安全来源：网络整理

导读：比较Scala 2.7.7(最新的2.7.x版本)与Scala 2.8.1(最新的2.8.x版本)我收集了以下指标： Scala version | 2.7.7 2.8.1 ------------------------------------------------ Compressed jar file | 3.6 MB 6.2 MB Uncompressed files | 8.3 MB 16.5 MB .class fi

比较Scala 2.7.7(最新的2.7.x版本)与Scala 2.8.1(最新的2.8.x版本)我收集了以下指标：

Scala version        |    2.7.7          2.8.1                              
------------------------------------------------
 Compressed jar file  |   3.6 MB         6.2 MB   
 Uncompressed files   |   8.3 MB        16.5 MB
 .class files in .    |   1.8 MB         1.7 MB
   in ./actors        | 554.0 KB         1.3 MB      
   in ./annotation    |   962  B        11.7 KB 
   in ./collection    |   2.8 MB         8.8 MB
   in ./compat        |   3.8 3B         3.8 KB
   in ./concurrent    | 107.3 KB       228.0 KB
   in ./io            | 175.7 KB       210.6 KB
   in ./math          |    ---         337.5 KB
   in ./mobile        |  40.8 KB        47.3 KB
   in ./ref           |  21.8 KB        26.5 KB 
   in ./reflect       | 213.9 KB       940.5 KB
   in ./runtime       | 271.0 KB       338.9 KB
   in ./testing       |  47.1 KB        53.0 KB
   in ./text          |  27.6 KB        34.4 KB
   in ./util          |   1.6 MB         1.4 MB       
   in ./xml           | 738.9 KB         1.1 MB

最大的罪犯是scala.collection(3.1倍大)和scala.reflect(4.4倍大)。
收集包的增加与2.8的整个集合框架的大改写的时间框架相同，所以我猜这是原因。

我一直认为，这种类型的系统魔法计算集合类方法的最佳返回类型(这是2.8的大变化)将在编译时完成，之后将不可见。

>为什么重写会导致大小的这么大的增加？

据我所知，它计划改进scala.io，scala.reflect和scala.swing，至少有两个其他actor库做的相同，而不是scala.actor(Lift actors)或者更多(Akka)和
scala.testing正式已被第三方测试库取代。

>改进的scala.io，scala.reflect或scala.swing会导致可比较的大小增加还是scala.collection的情况是一种非常特殊的情况？
>如果JDK 8中有一个可用的模块化系统，那么它被认为是将actors实现委托给Lift或者Akka？
>有没有计划最终删除scala.testing或从库jar文件拆分？
>可能在JDK7 / JDK8中包含SAM类型，Defender方法或MethodHandles可能会减少Scala编译器为匿名/内部类/单身人士/等等生成的类的数量。

解决方法

我与Scala项目或支持它的任何公司无关。所以把下面的一切当作我自己的个人意见

Why did the rewrite result in such a big increase in size?

最有可能的不是重写本身，而是specialization.特别是这个Function1定义：

trait Function1[@specialized(scala.Int,scala.Long,scala.Float,scala.Double) -T1,@specialized(scala.Unit,scala.Boolean,scala.Int,scala.Double) +R]

意味着Function1中的所有方法将被执行35次(每个Int，Long，Float，Double和AnyRef每个Unit单位，Boolean，Int，Float，Long，Double和AnyRef

现在，看看Scaladoc，看看Function1的已知子类。我甚至不会在这里复制它。还有专业的功能和功能2，尽管它们的影响要小得多。

如果有什么，我敢打赌重写减少最后的足迹，因为广泛的代码重用它启用。

为了反映，从几乎不存在，向新的收藏图书馆提供基本特征，所以相对增加并不奇怪。

Will an improved scala.io,scala.reflect or scala.swing result in a comparable size increase or was the case of scala.collection a really special circumstance?

不可比拟，因为重写与它无关。然而，一个真正的scala.io图书馆肯定会比现在那样大一点，而且我期待同样的Scala的真实反思系统(有关于后者的论文)。对于swing，我不认为它有很多但是增量的改进，主要是Java库的封装，所以我怀疑它的大小会变化很大。

Is it considered to delegate the actors implementation to Lift or Akka,if there will be an usable modularization system in JDK 8?

每个实施都有自己的优势，而且暂时还没有看到任何收敛的迹象。对于JDK 8，Scala应该与JDK 5兼容，而JDK 8的模块化？我并不是说这是不可能的，但对于可用的资源来说，这很有可能是太多的努力。

Are there plans to finally remove scala.testing or split it from the library jar-file?

已经讨论过，但也有一个关于为编译器本身提供某种测试框架，第三方测试框架不具备灵活性的问题。但是，可能会将其移动(或删除并替换为其他内容)到编译器jar。

Might the inclusion of SAM types,Defender Methods or MethodHandles in JDK7/JDK8 lead to a possibility of reducing the amount of classes the Scala compiler has to generate for anonymous/inner class/singletons/etc.?

当然，一旦没有人再使用JDK5 / JDK6了。当然，如果JDK7 / JDK8得到广泛的采用，并且改进是非常有价值的，那么Scala可以通过它的库的两个不同的jar文件来分发。但是，在这一点上，提出假设的情景还为时尚早。

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!