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

Optimization ideas for range retracing #99

Open
LinqLover opened this issue Aug 1, 2022 · 0 comments
Open

Optimization ideas for range retracing #99

LinqLover opened this issue Aug 1, 2022 · 0 comments
Labels
engineering Technical change to the machinery

Comments

@LinqLover
Copy link
Collaborator

LinqLover commented Aug 1, 2022

  • Share simulator caches #82

  • Join semantics for forks

    After two forked processes have the same control flow again, join them.

    • challenge: How to detect joinable processes? Return from the same method? How does this affect execution order of different branches?
  • Complex index structures for memory slices

    If memory slice indexes could have "gaps", we could reduce the number of forks significantly. For instance, for thisContext tdbRetracingTimeIndex even asString, we would only require 2 instead of n forks.

    • challenge: How does an efficient object layout for such indexes look like? How can we transform, combine, and merge such slices efficiently?
  • Streaming of results

    To improve the interactivity of slow range queries, we could use something like a (buffered) generator to display all results iteratively. Problems with this, however, include:

    • Iteration/update overhead can be pretty high
    • Especially in combination with join semantics/complex index structures, it turns out that streaming would expect a contrary scheduling scheme (more SIMD = fewer total time != fewer time to first result)
  • Optimize further bytecodes, in particular:

    • primitive 168 (primitiveCopyObject)
    • primitive 83/84/100 (perform/execute prims) to work like message sends
    • cloning might benefit from bulk access to memory
    • honor the actual number of numArgs for all unknown primitives to avoid superfluous vector checks/combinations/forks - at the moment, we sometimes even seem to do forks for Quick Push Const Methods)
  • Further experiments: How much speed could we gain ...

    • ... by not reusing the non-simulated stack from the caller but using a fresh process?
    • ... by setting the contextAtEachStep block to nil and avoiding to evaluate it?
    • ... by avoiding redundant copies/coalescions/transformations of vectors?
  • Hand-crafted client optimizations (e.g., for TDBHistoryExplorer>>#detailsTextForFormValue:, extract non-crucial part to not happen inside simulation)

For all of this, using the benchmark runner again would be very beneficial.

@LinqLover LinqLover added the engineering Technical change to the machinery label Aug 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
engineering Technical change to the machinery
Projects
None yet
Development

No branches or pull requests

1 participant