You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@arrow.apache.org by "Paul Taylor (Jira)" <ji...@apache.org> on 2021/02/05 05:25:00 UTC

[jira] [Commented] (ARROW-11351) Reconsider proxy objects instead of defineProperty

    [ https://issues.apache.org/jira/browse/ARROW-11351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17279344#comment-17279344 ] 

Paul Taylor commented on ARROW-11351:
-------------------------------------

[~domoritz] The Map/Proxy approach was introduced in https://github.com/apache/arrow/pull/5371.

The issue is the Arrow MapVector is a list of objects whose fields can vary per row. Because of this, we can't take advantage of the Object.defineProperties() flyweight pattern optimization like we can with StructVector.

But all is not lost! The Proxy approach allows us to at least defer the cost of deserializing each MapRow's key to lookup time, so creation is relatively fast (compared to deserializing each MapRow into an Object), and you only pay deserialization cost for fields you actually access.

This shouldn't affect the StructVector, as it still uses the Object.defineProperties() flyweight pattern.

> Reconsider proxy objects instead of defineProperty
> --------------------------------------------------
>
>                 Key: ARROW-11351
>                 URL: https://issues.apache.org/jira/browse/ARROW-11351
>             Project: Apache Arrow
>          Issue Type: Improvement
>          Components: JavaScript
>            Reporter: Dominik Moritz
>            Priority: Major
>
> I was wondering why Arrow uses Proxy objects instead of defineProperty, which was a bit faster in the experiments at https://observablehq.com/@jheer/from-apache-arrow-to-javascript-objects. I don't know whether a change makes sense but I would love to know the design rationale since I couldn't find anything in the issues or on GitHub about it. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)