Github user kiszk commented on the pull request:
https://github.com/apache/spark/pull/11307#issuecomment-187555111
There are three values of doing this.
a. **Make APIs clean and readable**: A mandatory set ofAPIs are well
represented by introducing such an abstract class. The values of a. is already
shown by introducing ``InternalRow``
b. **Abstract implementation of columnar storage**: To use accessors
defined in an abstract class, generated code and runtime code for operations
can be portable among different types of columnar storage. For example,
``ColumnVector``, ``ColumnAccessor``, and possible Apache Arrow.
In the current generated code of whole stage code gen, accesses to
elements is well abstracted. The generated code does not take care of an actual
class of ``InternalRow``.
The values of b. is already shown by introducing ``InternalRow``
````
protected void processNext() throws java.io.IOException {
while (input.hasNext()) {
InternalRow inputadapter_row = (InternalRow) input.next();
boolean inputadapter_isNull = inputadapter_row.isNullAt(0)
...
````
c. **Do not degrade runtime performance**: If we make getter methods final,
JIT compiler will inline these method and eliminate method calls. Thus, this
abstraction does not degrade performance, as done in `InternalRow`. The values
of c. is already shown by introducing ``InternalRow``
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
