Ran
|
Jobs
3
|
Files
24
|
Run time
1min
|
Badge
Embed ▾
README BADGES
|
push
travis-ci
Convert "full" bitsets to runs #124 (#125) * Convert "full" bitsets to runs #124 When ORing two bitsets, the result can be "full" (cardinality = 1<<16). Checking for this occurrence is cheap. When it happens, it should be converted to a "full" run container. RunContainer.full helper method to cheaply create "full" run container * "Full" to run optimization to buffer containers MappeableRunContainer.full helper method to cheaply create "full" run container Adjust RunContainer.full array size. * "Full" to run optimization for lazy or operations All BitmapContainer.ilazy methods has cardinality = -1 inside, so it makes no sense to consider optimization there. The only valid place for that seems to be repairAfterLazy which has recalculated cardinality. All .lazyOr methods already converting to BitmapContainer if necessary so the BitmapContainer.repair method will affect it too. * Reduce memory usage during tests Array containers were too big in some cases * "Full" to run - optimization for lazy OR operations on buffers * (lazy)bring two RunContainers inefficient array The result valuesLength was sometimes very big. This allows to return much smaller array. * Extract isFull() method for (Mappeable)BitmapContainer * When ORing BitmapContainer with other BC worth to track cardinality There is a pretty good chance we might end up with a full container, we should check for it as it is a great optimization. * Add me as a contributor * Added missing Full optimization * Revert "When ORing BitmapContainer with other BC worth to track cardinality" This reverts commit 90d5e4a19.
9407 of 10478 relevant lines covered (89.78%)
2.65 hits per line
ID | Job ID | Ran | Files | Coverage | |
---|---|---|---|---|---|
1 | 818.1 | 24 |
89.78 |
Travis Job 818.1 | |
2 | 818.2 | 24 |
89.71 |
Travis Job 818.2 | |
3 | 818.3 | 24 |
89.71 |
Travis Job 818.3 |
Coverage | ∆ | File | Lines | Relevant | Covered | Missed | Hits/Line |
---|