Remove overhead of calls from Table java code into Enso code by refactoring the functionality to Enso #6292
Labels
--low-performance
-compiler
-libs
Libraries: New libraries to be implemented
l-apache-arrow
InMemory Table move to Apache Arrow
x-on-hold
Comments
Akirathan
added
-compiler
-libs
|
This should include moving the callback part of the MultiValueIndex and other MultiValueKey methods to Enso too, so that we avoid all Java-to-Enso callbacks in the Table library. |
|
Once we move the |
radeusgd
added a commit
that referenced
this issue
May 29, 2023
radeusgd
added a commit
that referenced
this issue
May 30, 2023
radeusgd
added a commit
that referenced
this issue
May 30, 2023
|
First steps towards this done in #6890 |
radeusgd
added a commit
that referenced
this issue
May 31, 2023
radeusgd
added a commit
that referenced
this issue
May 31, 2023
radeusgd
added a commit
that referenced
this issue
Jun 1, 2023
radeusgd
added a commit
that referenced
this issue
Jun 2, 2023
mergify bot
pushed a commit
that referenced
this issue
Jun 2, 2023
Closes #5227 # Important Notes - This lays first steps towards #6292 - we get pure Enso variants of MultiValueKey. - Another part refactors `LongStorage` into `AbstractLongStorage` allowing it to provide alternative implementations of the underlying storage, in our case `LongRangeStorage` generating the values ad-hoc and `LongConstantStorage` - currently unused but in the future it can be adapted to support constant columns (once we implement similar facilities for other types).
5 tasks
|
PR #7270 |
11 tasks
|
This is on hold and should be tackled as we work with the storage refactor. If we move to Apache Arrow this could be essential. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There is "Table.order_by object" benchmark that creates a table consisting solely of
Myatoms with customMy_Comparatorand most of the time is spent in ObjectComparator.ensoCompare which calls back into Enso from Java across a boundary.The simplest, and quickest possible solution to speed up the performance is to move some of the functionality, that is currently implemented in
org.enso.base.tableJava package into Enso such that these kinds of callbacks are no longer necessary.After moving the functionality to Enso, it is possible that there may not be a need for a shared code between libs and runtime anymore (#5259).
The text was updated successfully, but these errors were encountered: