为什么Scala的库大小在2.7到2.8之间？

Question

将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中有可用的模块化系统,是否考虑将actor实现委托给Lift或Akka？

• 是否有计划最终删除scala.testing或将其从库jar文件中拆分？

• 可能在JDK7/JDK8中包含SAM类型,Defender方法或MethodHandles会导致减少Scala编译器必须为匿名/内部类/单例/等生成的类的数量.

Answer 1

专业化是一个因素(罐子增加约0.9MB).另一个因素是集合库,它现在在更大的实现类型集上统一实现更大的操作集.很多增加仅在字节码中,因为新的集合库非常大量地使用mixin组合,这往往会增加类文件的大小.我没有关于源文件大小的数据,但我相信它的增加量要小得多.

Answer 2

我与Scala项目或任何支持它的公司没有任何关联.因此,请将以下所有内容作为我个人的观点·

• 为什么重写导致大小如此大的增加？

最有可能的,不是重写本身,而是专业化.特别是,这个定义Function1:

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

意味着在所有方法Function1将实施35次(每个的Int,Long,Float,Double和AnyRef T1次,每次Unit,Boolean,Int,Float,Long,Double和AnyRef R.

现在,看看Scaladoc,看到知子类的Function1.我甚至不打算在这里复制它.还专门在那里Function0和Function2,虽然他们的影响要小得多.

如果有的话,我敢打赌重写会减少最终的占用空间,因为它启用了大量的代码重用.

至于reflect它,从几乎不存在到为新的集合库提供基本功能,所以毫不奇怪它有相对大的增长.

• 改进的scala.io,scala.reflect或scala.swing是否会导致相同的大小增加或scala.collection的情况是否真的特殊？

没有可比性,因为重写与它无关.然而,真正的scala.io图书馆肯定会比现在存在的图书馆大得多,而且我期望Scala真正的反思系统(有关于后者的论文).至于swing,我认为它没有多少但是逐步改进,主要是围绕Java库的包装,所以我怀疑它的大小会有很大变化.

• 如果在JDK 8中有可用的模块化系统,是否考虑将actor实现委托给Lift或Akka？

每个实现都有自己的优势,我暂时没有看到任何收敛的迹象.对于JDK 8,Scala如何与JDK 5兼容,同时为JDK 8进行模块化？我并不是说这是不可能的,但可能对可用资源的努力太多了.

• 是否有计划最终删除scala.testing或将其从库jar文件中拆分？

它已被讨论,但也有一个关于有关注一些排序可用于编译器本身测试框架的,具有灵活性第三方测试框架不会提供.不过,它可能会被移动(或移除并替换为其他东西)到编译器 jar.

• 可能在JDK7/JDK8中包含SAM类型,Defender方法或MethodHandles会导致减少Scala编译器必须为匿名/内部类/单例/等生成的类的数量.

当然,一旦没有人再使用JDK5/JDK6了.当然,如果JDK7/JDK8得到广泛采用并且改进非常值得,那么Scala可能会为其库分配两个不同的jar文件.但是,在这一点上,现在提出假设情景还为时过早.

Answer 3

我的猜测是,尺寸的增加并非来自重写但由于专业化的2.8启用引入这种类型的参数/.