You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
i) basic data generation template to generate data for integers, longs, binary column types (we can extend to include any arbitrary types and schema)
ii) In-memory data buffers to hold the generated data in the memory (either on on or off heap buffers).
iii) readers to consume the generated data using various APIs (calling get*(), or the holder API variant, or just writing your own readers from the direct byte buffers).
The whole benchmark is multi-threaded and all 3 steps can be done in parallel. It is the last step usually what is benchmarked. Obviously the current code base has a whole lot more code for my own testing and understanding, but we can clean it up gradually.
Where do we want to have this code? and how should a user run this? May be part of the default build process where benchmark is compiled as a separate jar (arrow-java-benchmarks-0.12.jar, something like this)
Wes McKinney / @wesm:
Since we're planning to start a benchmark database, it would be good timing to start writing some Java benchmarks. Is anyone interested in this?
Todd Farmer / @toddfarmer:
This issue was last updated over 90 days ago, which may be an indication it is no longer being actively worked. To better reflect the current state, the issue is being unassigned. Please feel free to re-take assignment of the issue if it is being actively worked, or if you plan to start that work soon.
@animeshtrivedi has done some microbenchmarking with the Java API. Let's consider adding them to the codebase.
Reporter: Li Jin / @icexelloss
Related issues:
Note: This issue was originally created as ARROW-3496. Please see the migration documentation for further details.
The text was updated successfully, but these errors were encountered: