Hi Jacques and Micah,
Thanks for the fruitful discussion.
It seems netty based allocator and unsafe based allocator have their
specific advantages.
Maybe we can implement both as independent allocators, to support different
scenarios.
This should not be difficult, as [1] has laid a solid ground
Wes McKinney created ARROW-7614:
---
Summary: [Python] Slow performance in
test_parquet.py::test_set_data_page_size
Key: ARROW-7614
URL: https://issues.apache.org/jira/browse/ARROW-7614
Project: Apache Arr
Hmm, somehow I missed those two alternatives, thanks for pointing them out.
I agree that these are probably better than taking a new dependency. Of
the two of them, it seems like using Unsafe directly might be better since
it would also solve a the issue of setting special environment variables
f
I think we are all broadly thinking along the same lines.
I would mention that I don't see "unsafe" as a problem that needs to be removed
per-se, it has it's place especially in libraries that are lower level like
Arrow.
I do have a problem with the fact that "value" (which is safe) has a comme
It seems like jna is overkill & unnecessary for simply allocating/freeing
memory.
A simple way to do this is either to use unsafe directly or call the
existing netty unsafe facade directly.
PlatformDependent.allocateMemory(long)
PlatformDependent.freeMemory(long)
Should be relatively straightfor
Arrow Build Report for Job nightly-2020-01-19-0
All tasks:
https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-01-19-0
Failed Tasks:
- gandiva-jar-osx:
URL:
https://github.com/ursa-labs/crossbow/branches/all?query=nightly-2020-01-19-0-travis-gandiva-jar-osx
- test-conda-py
