Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigation: custom Vertex storage #9

Open
jandam opened this issue Jan 26, 2017 · 1 comment
Open

Investigation: custom Vertex storage #9

jandam opened this issue Jan 26, 2017 · 1 comment

Comments

@jandam
Copy link

jandam commented Jan 26, 2017

I want to investigate possibility to introduce custom storage format for Vertex lists.
My idea is to have Vertex storage that will be accessed by integer index. It will have performance impact but decreasing memory demand.
For example my vertex data can use 2x int for XY and 1x short for Z value stored in 1 dimensional arrays. No memory overhead for Vertex as Java object.

No action required.

@gwlucastrig
Copy link
Owner

An excellent idea!

One unfortunate thing about Java is that it consumes 12 or 16 bytes per object instance (depending on the operating system and JVM). For a small object like a vertex, that means that a substantial part of the storage for the object is actually overhead.

I can see where you might end up making something like a "Semi-Virtual Vertex Store" for vertices. The Store would be a kind of collection that holds vertices, but keeps them in data rather than realizing them as objects... sort of what the SemiVirtualEdgePool does.

If you look at the SingleBuildTest, you will see where I use it to estimate the number of bytes used by different objects. It's a bit tricky because Java, by design, hides that kind of detail from the application. Anyway, as you're experimenting, you might be able to take some ideas from that as a way of evaluating your success.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants