Opened 6 years ago

Closed 4 years ago

#507 closed change (rejected)

[Typed objects] Implement a light-weight array.slice() method

Reported by: trev Assignee: kzar
Priority: P5 Milestone:
Module: Core Keywords:
Cc: Blocked By:
Blocking: #145 Platform: Unknown
Ready: yes Confidential: no
Tester: Unknown Verified working: no
Review URL(s):



In case of filters we will often have to work with a large string (complete filter text) as well as a number of its substrings (regexp source, options, domains etc). Creating the substrings via string constructor is suboptimal as it will copy the string data.

What to change

Implement an array.slice() method that will create a second array object accessing a subset of the original array's data. No copy operation should be necessary, the new array should simply have its arrayBufferIndex, arrayByteOffset and length properties set in such a way that they will point into the data of the original array. In order to prevent reallocations the length property should be made read-only for all slices as well as arrays that had slices created for them. Also, slices should keep a reference to the original array to prevent it from being garbage collected before them.

Change History (5)

comment:1 Changed 5 years ago by kzar

  • Owner set to kzar
  • Platform set to Unknown

comment:2 Changed 5 years ago by kzar

  • Review URL(s) modified (diff)
  • Tester set to Unknown

comment:3 Changed 5 years ago by kzar

  • Status changed from new to reviewing

comment:4 Changed 4 years ago by fhd

  • Priority changed from P2 to P5

Since the Emscripten based approach is looking rather good, I'm not sure we really want to continue to work on Typed Objects. Makes it a P5.

comment:5 Changed 4 years ago by trev

  • Resolution set to rejected
  • Status changed from reviewing to closed

In fact, at that point I am certain that we are dropping typed objects and go with Emscripten instead. The performance issues we had with Emscripten initially are bound to affect us with typed objects as well (important points: static generation of JS bindings, stack-based allocations, likely more). Fixing these issues was already non-trivial with Emscripten, but with our own toolchain it will require far more effort - this isn't going to pay off if we have a reasonable and maintained alternative.

Note: See TracTickets for help on using tickets.