- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Re: Size of standard library and possible tricks to reduce its size
Tue, 2011-10-18, 23:37
On Tue, Oct 18, 2011 at 3:33 PM, martin odersky wrote:
> You certainly are. But I do not see yet what it has to do with the problem
> that was reported earlier.
As it says in the ticket, "this bug may have stood between me and a
solution to SI-2876." In other words, I was restructuring the views to
get the linearization right, and ran directly into that bug. Not
having the luxury of shaving that particular yak, I reverted.
Wed, 2011-10-19, 14:27
#2
Re: Size of standard library and possible tricks to reduce its
2011/10/19 √iktor Ҡlang :
> Indeed, since it doesn't need to warm up the different implementations. :-)
There is also the JIT inlining aspect. HotSpot relies on bytecode size
to compute what to inline and the indirection introduced by the trait
forwarders may cause problems. I haven't had the chance to do specific
benchmarking around this, but I've seen some performance results that
could be explained by that.
Best,
Ismael
Wed, 2011-10-19, 14:37
#3
Re: Size of standard library and possible tricks to reduce its
On Wed, Oct 19, 2011 at 3:17 PM, Ismael Juma <ismael@juma.me.uk> wrote:
2011/10/19 √iktor Ҡlang <viktor.klang@gmail.com>:
> Indeed, since it doesn't need to warm up the different implementations. :-)
There is also the JIT inlining aspect. HotSpot relies on bytecode size
to compute what to inline and the indirection introduced by the trait
forwarders may cause problems. I haven't had the chance to do specific
benchmarking around this, but I've seen some performance results that
could be explained by that.
You mean that the bloat is pushing other optimizable things out of the boundary of the machinecode budget?
Best,
Ismael
--
Viktor Klang
Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts
Twitter: @viktorklang
Wed, 2011-10-19, 15:07
#4
Re: Size of standard library and possible tricks to reduce its
2011/10/19 √iktor Ҡlang :
> You mean that the bloat is pushing other optimizable things out of the
> boundary of the machinecode budget?
The bytecode inlining budget, yes. There is also a limit to the number
of methods HotSpot will inline, which is also a potential issue.
If HotSpot relied on the generated code to compute its inlining
budget, then things would be different (and probably better, although
there are other complications in that case).
Best,
Ismael
On Wed, Oct 19, 2011 at 1:01 PM, Ismael Juma <mlists@juma.me.uk> wrote:
Indeed, since it doesn't need to warm up the different implementations. :-)
--
Viktor Klang
Akka Tech LeadTypesafe - Enterprise-Grade Scala from the Experts
Twitter: @viktorklang