incaseoftrouble
commented
7 years ago Two comments on this:
- I think it makes sense to add my naturals-util library in this process, too, since it serves the same purpose (abstract the primitive operations while keeping performance). Adapting it is quite simple (replace BitSet by NatBitSet and
new BitSet()byNatBitSets.set()). Bonus points for usingboundedSet(n):) - I'd argue for option 2. with a slight twist: Instead of including the bare minimum in the fastutil jar, we could simply add everything reasonable, expecting little to no change in the future. "Everything reasonable" mainly includes Sets / Maps involving
int,doubleandlongplus the implementations. This is more or less what is currently needed and I'd bet there won't be much more. The jar will have roughly 2-3MB, if I recall correctly.
kleinj
davexparker
fastutil (github: https://github.com/vigna/fastutil) is a Java library that provides variants of Java's generic data structures, specialized for the primitive types and thus avoiding boxing ints, doubles, etc into Integers, Doubles, ...
This often improves performance and memory requirements, so it has been used by several groups in their PRISM extensions. We'd thus like to make it available in the main PRISM.
fastutil uses a templating approach to generate the Java source files for various instantiations (
Long2BooleanMap, ...), which results in a large number of classes, leading to the question of how to package it for PRISM in a smart way - without unnecessarily increasing compile times, download size/time and git repository size. @incaseoftrouble and I had some discussions about the options:lib. Currently, that would be a 17MB binary blob. It would also change every time we want to include a new fastutil release. To get convenient JavaDocs for the classes in the IDEs, we'd have to include the source files (15MB compressed, 77MB uncompressed) in the JAR.lib. There are tools that can automatically cull a JAR file to only include those classes that are actually used. That would probably reduce the JAR size quite a bit, because there are a ton of fastutil classes that will probably never be used by PRISM (e.g., all 'short', 'byte' and 'float' specializations). There is then the complication that every time some PRISM developer wants to use some previously unused part of fastutil, we'd have to rebuild the JAR and drop a new binary blob. In particular, that would complicate merging of pull requests.jdepstool to find the dependencies and write the corresponding.javafilenames in a text file. This would allow some automatic way to copy/keep exactly the required files. Benefits are that merging PRs, updating to a new fastutil version, importing additional fastutil classes would be regular git operations on the Java sources.If the actual number of files that are needed is reasonable, my personal preference would be for option 3. In that case, I think the following approach makes sense: You'd have one text file that lists the fastutil dependencies that result from the PRISM source, i.e., those classes that are directly imported into PRISM source code. In a seperate step, one could then generate the list of fastutil dependencies for those classes, i.e., the dependencies inside fastutil, and include all these
.javasource files. In addition, it should be possibly to manually add fastutil classes to the first list, e.g., because one knows that those classes are generally useful or used in some branch. It would then be sensible to have some script support to automate the usual tasks (update to a new fastutil version, updating the java files according to the dependencies, ...).