Hey all,

(~beginner to V8 internals!)

We have a use case which does high frequency lambda-like JS function 
execution across any/multiple threads in a constrained environment 
(Android) which has heavy cost for malloc.

In local on-device benchmarking, we noticed grabbing the V8::EntryScope on 
every lambda-like function call does a few malloc/free pairs, specifically:
* Context::Enter uses two DetachableVectors for the first time (once each) 
which mallocs space
* HandleScope::CreateHandle uses a DetachableVector for the first time 
(once) which mallocs space
* Destruction of the V8::EntryScope frees this space

For our case which rarely nests v8::EntryScopes and creates/frees them in 
pairs at high frequency, it would be more efficient (overall) to use an 
absl::InlinedVector-like object which assumes at least one (but up to N) 
Handles will be created / Contexts will be entered/saved. This shaved a few 
percent off our minimal overhead numbers. Naturally this would use up more 
initial space, though I expect the situations where a V8::EntryScope are 
created and *never* used are rare?

I am happy to make this contribution, but want to validate I'm not missing 
some subtlety, and wanted to generally ask for permission before going 
through the process! I expect this would be generally useful for other 
lambda-like use cases such as edge functions, Cloudflare Workers, etc.

My intended implementation would:
* have DetachableVector be backed by an absl::InlinedVector of size 
kMinimumCapacity (8)
* Optional?: have minimum capacity controlled by compile-time flag (could 
be default 0 and not inline anything!)

Thanks!

Konnor


-- 
-- 
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
--- 
You received this message because you are subscribed to the Google Groups 
"v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-dev/4efa5937-0dce-445c-9d35-9efba105dec9n%40googlegroups.com.

Reply via email to