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

Dart script start time appears to be significantly longer than Javascript's #17997

Closed
blois opened this issue Apr 2, 2014 · 19 comments
Closed
Assignees
Labels
P1 A high priority bug; for example, a single project is unusable or has many test failures
Milestone

Comments

@blois
Copy link
Contributor

blois commented Apr 2, 2014

This could be that the JS VM is starting up earlier, but given the two HTML pages below, the Javascript time is 0.5-3ms while the Dart time is ~350ms.

If only window.performance.now() is used (measuring from navigation start, inclusive of server response time), then my Javascript times go to 15-20ms. The addition of 15-20ms is in the noise range for Dart.

---- Javascript
<!doctype html>
<body>
  <script>
    var elapsed = window.performance.now() + window.performance.timing.navigationStart - window.performance.timing.domLoading
    document.body.appendChild(document.createTextNode(elapsed));
  </script>
</body>

---- Dart
<!doctype html>
<body>
  <script type='application/dart'>
    import 'dart:html';
    main() {
      var elapsed = window.performance.now() + window.performance.timing.navigationStart - window.performance.timing.domLoading;
      document.body.append(new Text(elapsed.toString()));
    }
  </script>
</body>

@blois
Copy link
Contributor Author

blois commented Apr 2, 2014

Note- this was measured on my desktop dev machine.

@a-siva
Copy link
Contributor

a-siva commented Apr 4, 2014

On my desktop I see the following numbers:
JS version 1.2 - 1.5
Dart version 99 - 106

Using --time-all I see that we get
Script Loading : 90 micros.
Snapshot Creation : 0 micros.
Isolate initialization : 15413 micros.
Function compilation : 271 micros.
Bootstrap of core classes : 39 micros.
Dart execution : 0 micros.
Total runtime for isolate : 147 micros.

(time spent in the VM during initialization seems to be about 15 ms, we need to find out where the other 75 ms is going)

@a-siva
Copy link
Contributor

a-siva commented Apr 4, 2014

Profiling the startup shows most of the ticks from core chrome, there are a few
ticks for libblink but they are not the top ticks.

  • 46.18% chrome [kernel.kallsyms] [k] 0xffffffff8103b51a ▒
  • 10.10% chrome ld-2.15.so [.] do_lookup_x ▒
  • 2.41% chrome libc-2.15.so [.] __memset_sse2 ◆
  • 1.68% chrome ld-2.15.so [.] _dl_lookup_symbol_x ▒
  • 1.37% chrome libnvidia-glcore.so.319.32 [.] 0x14af8dc ▒
  • 1.34% chrome glbplrWU (deleted) [.] 0x1e3a ▒
  • 1.32% chrome ld-2.15.so [.] _dl_relocate_object ▒
  • 0.87% chrome libc-2.15.so [.] __memcpy_ssse3_back ▒
  • 0.78% chrome libc-2.15.so [.] __memmove_ssse3_back ▒
  • 0.75% chrome ld-2.15.so [.] strcmp ▒
  • 0.75% lsb_release [kernel.kallsyms] [k] 0xffffffff8103b51a ▒
  • 0.59% chrome ld-2.15.so [.] check_match.11236 ▒
  • 0.59% lsb_release python2.7 [.] PyString_FromString ▒
  • 0.53% chrome chrome [.] tc_malloc ▒
  • 0.51% chrome libpthread-2.15.so [.] pthread_mutex_lock ▒
  • 0.45% chrome libblink_web.so [.] dart::SnapshotReader:▒
  • 0.44% chrome chrome [.] operator new(unsigned▒
  • 0.39% nacl_helper [kernel.kallsyms] [k] 0xffffffff8103b51a ▒
  • 0.37% lsb_release python2.7 [.] PyEval_EvalFrameEx ▒
  • 0.32% chrome libbase.so [.] base::subtle::RefCoun▒
  • 0.31% chrome libGL.so.319.32 [.] 0xabe9e ▒
  • 0.30% nacl_helper ld-2.15.so [.] do_lookup_x ▒
  • 0.29% chrome libpthread-2.15.so [.] pthread_getspecific ▒
  • 0.29% chrome libc-2.15.so [.] __sched_yield ▒
  • 0.28% chrome libbase.so [.] base::subtle::RefCoun▒
  • 0.28% chrome libbase.so [.] base::internal::Callb▒
  • 0.28% chrome libfreetype.so.6.8.0 [.] 0x1e1db ▒
  • 0.27% chrome libpthread-2.15.so [.] pthread_mutex_unlock ▒
  • 0.27% chrome libcontent.so [.] _ZN3IPC7MessageC1ERKS▒
  • 0.27% chrome libglib-2.0.so.0.3200.4 [.] 0x5baea ▒
  • 0.27% chrome libpthread-2.15.so [.] pthread_rwlock_unlock▒
  • 0.27% chrome libfontconfig.so.1.4.4 [.] FcCompareFamily ▒
  • 0.26% chrome libbase.so [.] logging::get_dcheck_s▒
  • 0.26% chrome libpangoft2-1.0.so.0.3000.0 [.] Coverage::get_coverag▒
  • 0.25% chrome chrome [.] _ZN12_GLOBAL__N_121do▒
  • 0.23% chrome libc-2.15.so [.] _IO_vfscanf ▒
  • 0.23% chrome libc-2.15.so [.] __strcmp_sse42 ▒
  • 0.23% chrome ld-2.15.so [.] _dl_name_match_p ▒
  • 0.22% chrome [vdso] [.] 0x7fff81695828 ▒
  • 0.21% chrome libblink_web.so [.] dart::SnapshotReader:▒
  • 0.21% chrome libblink_web.so [.] dart::Symbols::FindIn▒
  • 0.20% chrome libglib-2.0.so.0.3200.4 [.] g_hash_table_lookup ▒
  • 0.20% chrome chrome [.] tcmalloc::CentralFree▒
  • 0.19% chrome libblink_web.so [.] dart::LiteralToken::R▒
  • 0.19% chrome libblink_web.so [.] dart::MarkingVisitor:▒
  • 0.19% chrome libfontconfig.so.1.4.4 [.] FcCompareValueList ▒
  • 0.18% chrome libblink_web.so [.] dart::VMHandles::Allo▒
  • 0.18% chrome libskia.so [.] sk_memset32_SSE2(unsi▒
  • 0.17% chrome librt-2.15.so [.] clock_gettime ▒
  • 0.17% chrome libgobject-2.0.so.0.3200.4 [.] g_object_unref ▒
  • 0.17% chrome libgfx.so [.] MOZ_Z_inflate_table ▒
  • 0.16% chrome libm-2.15.so [.] __ieee754_log_avx ▒
  • 0.16% chrome libnspr4.so [.] cvt_l ▒
  • 0.15% chrome libc-2.15.so [.] 0xf4a97 ▒
  • 0.14% chrome chrome [.] tc_realloc ▒
  • 0.14% chrome chrome [.] tcmalloc::PageHeap::S▒
  • 0.14% chrome libbase.so [.](anonymous namespace)▒
  • 0.13% chrome libblink_web.so [.] dart::Parser::Current▒
  • 0.13% chrome libstdc++.so.6.0.16 [.] std::_Rb_tree_increme▒
  • 0.13% chrome libblink_web.so [.] dart::TokenStream::It▒
  • 0.13% chrome libviews.so [.] views::View::child_at▒
  • 0.12% chrome libblink_web.so [.] dart::Object::initial▒
  • 0.12% nacl_helper ld-2.15.so [.] _dl_relocate_object ▒
  • 0.12% chrome libc-2.15.so [.] __memcmp_sse4_1 ▒
  • 0.12% chrome libblink_web.so [.] dart::AbstractType::i▒
  • 0.11% chrome libv8.so [.] v8::internal::Descrip▒
  • 0.11% chrome libglib-2.0.so.0.3200.4 [.] g_pointer_bit_unlock ▒
  • 0.11% chrome libgfx.so [.] MOZ_Z_inflate ▒
  • 0.11% chrome libbase.so [.](anonymous namespace)▒
  • 0.11% chrome libglib-2.0.so.0.3200.4 [.] g_slice_alloc ▒
  • 0.11% nacl_helper ld-2.15.so [.] _dl_lookup_symbol_x ▒
  • 0.11% chrome libblink_web.so [.] dart::Parser::CheckMe▒
  • 0.11% chrome libblink_web.so [.] dart::SnapshotReader:▒
  • 0.11% chrome libv8.so [.] v8::internal::Deseria▒

@a-siva
Copy link
Contributor

a-siva commented Apr 4, 2014

The corresponding profile for the JS version looks identical, we are probably idling somewhere.

  • 44.96% chrome [kernel.kallsyms] [k] 0xffffffff8103b◆
  • 11.33% chrome ld-2.15.so [.] do_lookup_x ▒
  • 2.88% chrome libc-2.15.so [.] __memset_sse2 ▒
  • 2.04% chrome ld-2.15.so [.] _dl_lookup_symb▒
  • 1.81% chrome glCUMVb7 (deleted) [.] 0x1e66 ▒
  • 1.58% chrome libc-2.15.so [.] __memcpy_ssse3_▒
  • 1.35% chrome libnvidia-glcore.so.319.32 [.] 0xf0723c ▒
  • 1.22% chrome ld-2.15.so [.] _dl_relocate_ob▒
  • 1.04% chrome libpthread-2.15.so [.] pthread_mutex_l▒
  • 0.94% lsb_release python2.7 [.] 0x1490b0 ▒
  • 0.81% chrome libc-2.15.so [.] __memmove_ssse3▒
  • 0.81% chrome ld-2.15.so [.] strcmp ▒
  • 0.67% chrome chrome [.] operator new(un▒
  • 0.65% lsb_release python2.7 [.] PyErr_Format ▒
  • 0.65% chrome libfreetype.so.6.8.0 [.] 0x4f58b ▒
  • 0.52% chrome ld-2.15.so [.] check_match.112▒
  • 0.51% chrome libGL.so.319.32 [.] 0xa3277 ▒
  • 0.50% chrome libbase.so [.] base::internal:▒
  • 0.46% chrome chrome [.] _ZN12_GLOBAL__N▒
  • 0.46% chrome libbase.so [.] logging::get_dc▒
  • 0.36% lsb_release [kernel.kallsyms] [k] 0xffffffff8103b▒
  • 0.35% chrome ld-2.15.so [.] _dl_name_match_▒
  • 0.34% chrome libglib-2.0.so.0.3200.4 [.] 0x83342 ▒
  • 0.34% nacl_helper [kernel.kallsyms] [k] 0xffffffff8103b▒
  • 0.34% chrome chrome [.] tcmalloc::Centr▒
  • 0.31% chrome libsql.so [.] releaseMemArray▒
  • 0.29% chrome libc-2.15.so [.] __memcmp_sse4_1▒
  • 0.29% chrome libglib-2.0.so.0.3200.4 [.] g_variant_type_▒
  • 0.28% chrome libgobject-2.0.so.0.3200.4 [.] 0x1a780 ▒
  • 0.27% chrome libbase.so [.] (anonymous name▒
  • 0.26% chrome chrome [.] tc_malloc ▒
  • 0.24% chrome libfontconfig.so.1.4.4 [.] FcConfigCompare▒
  • 0.23% chrome libfontconfig.so.1.4.4 [.] FcCompareFamily▒
  • 0.23% chrome libpangoft2-1.0.so.0.3000.0 [.] Coverage::get_c▒
  • 0.23% nacl_helper ld-2.15.so [.] _dl_lookup_symb▒
  • 0.21% chrome libpthread-2.15.so [.] pthread_cond_ti▒
  • 0.20% nacl_helper ld-2.15.so [.] do_lookup_x ▒
  • 0.20% chrome libc-2.15.so [.] __strchr_sse42 ▒
  • 0.20% chrome libc-2.15.so [.] __strcmp_sse42 ▒
  • 0.19% chrome libpthread-2.15.so [.] pthread_mutex_u▒
  • 0.18% chrome chrome [.] tcmalloc::Centr▒
  • 0.18% chrome libipc.so [.] IPC::internal::▒
  • 0.18% chrome libpthread-2.15.so [.] pthread_rwlock_▒
  • 0.18% chrome libc-2.15.so [.] __strlen_sse2_p▒
  • 0.17% chrome libglib-2.0.so.0.3200.4 [.] g_str_hash ▒
  • 0.17% chrome libc-2.15.so [.] __sched_yield ▒
  • 0.16% chrome libfontconfig.so.1.4.4 [.] FcCompareValueL▒
  • 0.16% chrome libfreebl3.so [.] felem_reduce_de▒
  • 0.16% chrome libskia.so [.] sk_memset32_SSE▒
  • 0.16% chrome libpthread-2.15.so [.] pthread_getspec▒
  • 0.16% chrome libcairo.so.2.11000.2 [.] glitter_scan_co▒
  • 0.15% chrome libbase.so [.] tracked_objects▒
  • 0.15% chrome libstdc++.so.6.0.16 [.] std::basic_stri▒
  • 0.15% chrome libgfx.so [.] color_utils::Sk▒
  • 0.15% chrome chrome [.] tc_calloc ▒
  • 0.14% chrome ld-2.15.so [.] _dl_map_object ▒
  • 0.14% chrome [vdso] [.] 0x7fff1cdff900 ▒
  • 0.13% chrome libpthread-2.15.so [.] pthread_rwlock_▒
  • 0.13% chrome chrome [.] tc_realloc ▒
  • 0.13% chrome libbase.so [.] base::subtle::R▒
  • 0.13% chrome chrome [.] tcmalloc::Centr▒
  • 0.12% chrome chrome [.] tcmalloc::PageH▒
  • 0.12% chrome libglib-2.0.so.0.3200.4 [.] g_main_context_▒
  • 0.12% chrome chrome [.] tcmalloc::Centr▒
  • 0.12% chrome libm-2.15.so [.] __ieee754_log_a▒
  • 0.12% chrome libskia.so [.] SkMatrix44::set▒
  • 0.12% nacl_helper ld-2.15.so [.] _dl_relocate_ob▒
  • 0.11% chrome librt-2.15.so [.] clock_gettime ▒
  • 0.11% chrome libskia.so [.] SkMatrix44::pre▒
  • 0.11% chrome libbase.so [.] base::subtle::R▒
  • 0.11% chrome libglib-2.0.so.0.3200.4 [.] g_slice_free1 ▒
  • 0.11% chrome libxcb.so.1.1.0 [.] poll_for_reply ▒
  • 0.11% chrome libbase_prefs.so [.] PrefNotifierImp▒
  • 0.11% chrome libcc.so [.] cc::MicroBenchm▒
  • 0.11% chrome libbase.so [.] tracked_objects▒

@a-siva
Copy link
Contributor

a-siva commented Apr 10, 2014

I commented out the following line DartDebugServer::shared().isolateLoaded();
from DartApplicationLoader::callEntryPoint() and the time now drops from

Dart version 99 - 106 to Dart version 42 - 45

Why do we do this initialization of loaded isolates code eagerly in the initialization path?

@a-siva
Copy link
Contributor

a-siva commented Apr 10, 2014

cc @jacob314.

@jacob314
Copy link
Member

This is a bug. DartDebugServer should never be called unless the devtools are open.

@a-siva
Copy link
Contributor

a-siva commented Apr 11, 2014

I was connected to devtools at that time as I was trying to use the timeline feature of devtools to see where the time was going.

@a-siva
Copy link
Contributor

a-siva commented Apr 11, 2014

Here is an analysis of the time spent without using devtools/timelines etc.

Initial load takes about 95 ms and the distribution is as follows:

  • service isolate creation 16 ms
  • service isolate singletons/closures setup 7 ms
  • service setup 20 ms
  • dom isolate creation 16 ms
  • dom isolate singletons/closures setup 7 ms
  • dom isolate debug server setup 12 ms
  • DartAsynLoader::initialize (creates an isolate) 16 ms
  • DartAsyncLoader::process 1 ms

Subsequent load takes about 41-42 ms and the distribution is as follows:

  • dom isolate creation 16 ms
  • dom isolate singletons/closures setup 7 ms
  • dom isolate debug server setup 2 ms
  • DartAsynLoader::initialize (creates an isolate) 16 ms
  • DartAsyncLoader::process 1 ms

Action items:

  • We need to ensure that DartAsyncLoader is fixed to not use a new isolate
  • not sure why the debug server needs to be initialized by default
  • we need to explore if the service isolate stuff can happen in the background

@blois
Copy link
Contributor Author

blois commented Apr 11, 2014

Have there been any recent improvements in load times? I'm now seeing
numbers in-line with what Siva reports, but was seeing them quite a bit
higher not long ago.

I'll re-check Android as well, as I was seeing ~800ms load times there.

@vsmenon
Copy link
Member

vsmenon commented Apr 11, 2014

I am working on merging DartAsyncLoader and DartApplicationLoader to single loader with a single isolate as part of my script changes. That should get 16 ms.

@a-siva
Copy link
Contributor

a-siva commented Apr 14, 2014

Marked this as being blocked by #18219.

@a-siva
Copy link
Contributor

a-siva commented Apr 14, 2014

Marked this as being blocked by #18220.

@a-siva
Copy link
Contributor

a-siva commented Apr 14, 2014

Marked this as being blocked by #18221.

@a-siva
Copy link
Contributor

a-siva commented Apr 14, 2014

Set owner to @a-siva.
Added Accepted label.

@a-siva
Copy link
Contributor

a-siva commented Apr 14, 2014

Issues 18219, 18220, 18221 have been created to track the 3 action items listed above.
This bug will be used to track the overall startup time and the issue of reducing general isolate startup times and the time needed to create singletons/closures etc.
which currently take about 23 ms (16 ms + 7 ms).

@a-siva
Copy link
Contributor

a-siva commented Apr 17, 2014

Bumping priority as application startup time has become a critical factor.


Removed Priority-Unassigned label.
Added Priority-High label.

@blois
Copy link
Contributor Author

blois commented Apr 21, 2014

Just tested on Android again, times appear to be in the range of ~630ms after a reboot of the device, depending on what's going on I've seen it go up to closer to 900ms.

Let me know if I can further assist.

@a-siva
Copy link
Contributor

a-siva commented Apr 21, 2014

Do you have the developers tools window open when you do this measurement?

@blois blois added Type-Defect P1 A high priority bug; for example, a single project is unusable or has many test failures labels Apr 21, 2014
@blois blois added this to the 1.9 milestone Apr 21, 2014
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P1 A high priority bug; for example, a single project is unusable or has many test failures
Projects
None yet
Development

No branches or pull requests

4 participants