Support deserialized compilation of the empty program.

pkg/compiler/lib/src/compiler.dart

 // Copyright (c) 2012, the Dart project authors.  Please see the AUTHORS file
 // for details. All rights reserved. Use of this source code is governed by a
 // BSD-style license that can be found in the LICENSE file.
 
 library dart2js.compiler_base;
 
 import 'dart:async' show EventSink, Future;
 
 import '../compiler_new.dart' as api;
 import 'cache_strategy.dart' show CacheStrategy;
@@ skipping 1832 matching lines @@
 
   @override
   DartType resolveTypeAnnotation(Element element, TypeAnnotation node) {
     return compiler.resolver.resolveTypeAnnotation(element, node);
   }
 
   @override
   bool hasResolvedAst(Element element) {
     assert(invariant(element, element.isDeclaration,
         message: "Element $element must be the declaration."));
+    if (compiler.serialization.isDeserialized(element)) {

[Siggi Cherem (dart-lang), 2016/04/19 20:58:02]

Could this be a possible cause of the regression?  We are doing this check now
on every access to fetch the resolved AST.

I thought about the following during the review, then forgot to bring it up: I
wonder how early we can remove any distinction between deserialized & parsed
element models. Today we hide it behind this `resolution` abstraction, but
instead of doing it on queries, we might be able to do it a bit earlier. 
My hope is that by the time we load a serialized file, we initialize the pieces
of the compiler to avoid having to reach into the serialization task at all
afterwards.

For this specific use case, maybe we can remove the distinctions when we first
construct the class? For example if we implement the resolvedAst getter in
modelz and we store the deserialized impact in the _worldImpactCache, could we
use the same codepath here for both parsed & deserialized elements?

[Johnni Winther, 2016/04/20 10:40:21]

For swarm SerializationTask.isDeserialized is called 73921 times, 27792 of these
from here. If find it surprising if that alone can create a 3% compile-time
increase.

[Siggi Cherem (dart-lang), 2016/04/20 18:58:40]

Yeah - I'm not sure, but this and the other changes to resolveAst could have
other effects for the VM, like making hasResolvedAst polymorphic (since now
there is a second implementation in the serialization task) or it can make
inlining of this method harder for the vm.

Just commenting the lines on this method doesn't justify a 3% regression (did
some perf testing that it only accounts for 0.3%), I'll look and see if
precomputing the `body` of a resolved AST is part of that cost.

+      return compiler.serialization.hasResolvedAst(element);
+    }
     return element is AstElement &&
         hasBeenResolved(element) &&
         element.hasResolvedAst;
   }
 
   @override
   ResolvedAst getResolvedAst(Element element) {
     assert(invariant(element, element.isDeclaration,
         message: "Element $element must be the declaration."));
     if (hasResolvedAst(element)) {
+      if (compiler.serialization.isDeserialized(element)) {
+        return compiler.serialization.getResolvedAst(element);
+      }
       AstElement astElement = element;
       return astElement.resolvedAst;
     }
     assert(invariant(element, hasResolvedAst(element),
         message: "ResolvedAst not available for $element."));
     return null;
   }
 
   @override
   bool hasResolutionImpact(Element element) {
@@ skipping 155 matching lines @@
   _ElementScanner(this.scanner);
   void scanLibrary(LibraryElement library) => scanner.scanLibrary(library);
   void scanUnit(CompilationUnitElement unit) => scanner.scan(unit);
 }
 
 class _EmptyEnvironment implements Environment {
   const _EmptyEnvironment();
 
   String valueOf(String key) => null;
 }