Execution slowdown issue

[Danny Dorfman]

Hello there,

I have an issue with some code running JavaScript under V8, The code runs in a single Isolate, that has one context.

The context is created, populated with some scripts, the scripts are executed, and then the context is Exit()ed. The Isolate stays intact.

The above sequence repeats itself several times, with the same scripts running time and again. This is what I call a series of "transactions".

What happens, is after the initial transaction is executed, all the subsequent ones experience a drastic slowdown (sometimes 7 times slower).

I tried profiling the code with oprofile, and I see this picture:

Fast transaction:

PU: Intel Ivy Bridge microarchitecture, speed 3401 MHz (estimated)

Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 100000

samples  %        image name           symbol name

2444      1.8590  libv8.so                 v8::internal::HandleScope::ZapRange(v8::internal::Object**, v8::internal::Object**)

1849      1.4064  libv8.so                 v8::internal::HeapObject::map() const

1537      1.1691  libv8.so                 v8::base::NoBarrier_Load(long const volatile*)

1417      1.0778  libv8.so                 v8::internal::SmiTagging<8ul>::SmiToInt(v8::internal::Object const*)

1286      0.9782  libv8.so                 v8::internal::FixedArrayBase::length() const

1273      0.9683  libpthread-2.13.so   pthread_getspecific

1250      0.9508  libv8.so                 v8::internal::MapWord::MapWord(unsigned long)

1235      0.9394  libv8.so                 v8::internal::FixedArray::get(int) const

1171      0.8907  libv8.so                 v8::base::Acquire_Load(long const volatile*)

1029      0.7827  libv8.so                 void v8::base::CallOnce<void>(long*, v8::base::OneArgFunction<void*>::type, void*)

1021      0.7766  libv8.so                 v8::internal::HeapObject::map_word() const

.....

Slow transaction:

CPU: Intel Ivy Bridge microarchitecture, speed 3401 MHz (estimated)

Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 100000

samples  %        image name           symbol name

27474     8.4737  libv8.so                 v8::internal::HeapObject::map() const

17271     5.3268  libv8.so                 v8::internal::MapWord::MapWord(unsigned long)

15862     4.8923  libv8.so                 v8::internal::Map::instance_type()

14754     4.5505  libv8.so                 v8::base::NoBarrier_Load(long const volatile*)

13941     4.2998  libv8.so                 v8::internal::HeapObject::map_word() const

13573     4.1863  libv8.so                 v8::internal::MapWord::FromRawValue(unsigned long)

11299     3.4849  libv8.so                 v8::internal::Internals::HasHeapObjectTag(v8::internal::Object const*)

10365     3.1968  libv8.so                 v8::internal::Object::IsInternalizedString() const

8469      2.6121  libv8.so                 v8::internal::HeapObject::cast(v8::internal::Object const*)

8085      2.4936  libv8.so                 v8::internal::Object::IsHeapObject() const

6350      1.9585  libv8.so                 v8::internal::Object::IsOddball() const

6105      1.8829  libv8.so                 v8::internal::Embedded::Embedded()

5777      1.7818  libv8.so                 v8::internal::MapWord::ToRawValue()

5670      1.7488  libv8.so                 v8::internal::MapWord::ToMap()

...

Any idea what is happening here? Why is the same code running so slowly the second (third, etc) time around?

Regards,

Danny

[Toon Verwaest]

If your transactional scripts contain function declarations that you instantiate, even if they are global, you'll inadvertantly cause polymorphism on the second run. That will slow down significantly. You can avoid this by only rerunning scripts that call/instantiate existing functions. Alternatively you can turn off the compilation cache; which will help with runtime (not load time though) if you reload all scripts.

(Btw, you might want to turn off handle zapping as well...)

Hth,
Toon

--
--
v8-users mailing list
v8-u...@googlegroups.com
http://groups.google.com/group/v8-users
---
You received this message because you are subscribed to the Google Groups "v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jakob Kummerow]

The profile for the "slow transaction" doesn't really say anything other than that the C++ compiler didn't do any inlining (probably due to oprofile, or was this a Debug build, or both?).

[Danny Dorfman]

Hi Jakob,

Yes, you're right. It was because of the debug build. Switching to the release version sped things up considerably.

Thanks! That was a quick fix :)

Regards,

Danny