The ultimate goal of HPPC is to address computationally-intensive scenarios as a priority. Encapsulation, fail-fast behaviour, thread-safety and beauty of the API are of secondary importance.
Assumption | Design implications |
---|---|
Programmers know what they're doing. In order to write highest-performing code, they may wish to access the internal storage of a collection directly rather than use the built-in iterators. | Simple data types, internal storage exposed for application-specific optimisations. HPPC provides utilities for the most common tasks like filtering, iterating or joining collections, but these are usually more expensive than direct access to the low-level data storage. |
No interfaces and class hierarchies. The programmer chooses the best collection implementation at design-time based on the desired characteristics. | |
No support for Java serialization. There are many other libraries that handle serialization. | |
Single-threaded access prevails. Vast majority of low-level computation code is single-threaded and therefore there is little point in verification of concurrent modifications and synchronization. | Not thread-safe implementations, concurrent modification attempts are not detected. |
Solid unit- and regression-testing. The programs that use primitive collections are heavily unit- and regression-tested during development, so their behavior in production systems does not have to be restrictively verified. | Optional verification. Verification of parameter and state validity is done optionally using assertions. This means that contracts are only checked if requested at runtime (using Java 1.4+ -ea switch). Production-ready code can run with no additional overhead from contract checks. |