[GraphHopper] Alternative to Trove library.

[Peter K]

Hey Alex,

I have not yet heard about this issue. There are alternatives to trove
but definitely not the standard collection libraries due to memory usage
and also performance. See also this issue:
https://github.com/graphhopper/graphhopper/issues/34

But I think this problem should be easily solvable via autojar or a
similar tools which remove unused classes of jars.

java -jar autojar-2.1/autojar.jar -o trove4j-stripped.jar -c
$TROVE/target/classes @trove-class.list

where trove-class.list is a file with the required classes for
GraphHopper as content**

Regards,
Peter.

**
gnu.trove.list.TDoubleList.class
gnu.trove.list.TIntList.class
gnu.trove.list.array.TDoubleArrayList.class
gnu.trove.list.array.TIntArrayList.class
gnu.trove.map.TIntObjectMap.class
gnu.trove.map.hash.TIntObjectHashMap.class
gnu.trove.map.hash.TIntIntHashMap.class
gnu.trove.set.hash.TIntHashSet.class
gnu.trove.iterator.TIntIterator.class
gnu.trove.procedure.TIntProcedure.class
gnu.trove.procedure.TObjectProcedure.class
gnu.trove.stack.array.TIntArrayStack.class


> Hi, 
>
> I don't know if this has been discussed before, but while developping
> my android app with graphhopper support I have hit the infamous dalvik
> error : 
> Conversion to Dalvik format failed with error 2 
> trouble writing output: Too many methods: 72332; max is 65536. By package:
>
> As per stackoverflow and android coummunity this is due to a too large
> codebase for my app = too many methods. 
>
> The error log gives me a method count per package and it seems the gnu
> trove which is used by graphhopper is very greedy in that domain. for
> example the error log give me 
>
>   446 gnu.trove
>   3066 gnu.trove.decorator
>      8 gnu.trove.function
>     13 gnu.trove.impl
>   1139 gnu.trove.impl.hash
>   2658 gnu.trove.impl.sync
>   3010 gnu.trove.impl.unmodifiable
>    404 gnu.trove.iterator
>      2 gnu.trove.iterator.hash
>    339 gnu.trove.list
>    602 gnu.trove.list.array
>    674 gnu.trove.list.linked
>   1763 gnu.trove.map
>    798 gnu.trove.map.custom_hash
>   8147 gnu.trove.map.hash
>     72 gnu.trove.procedure
>      2 gnu.trove.procedure.array
>     28 gnu.trove.queue
>    175 gnu.trove.set
>    396 gnu.trove.set.hash
>     56 gnu.trove.stack
>    133 gnu.trove.stack.array
>      6 gnu.trove.strategy
>
> TOTAL : 23'397 methods just for trove. WOW ! 
>
>
>
>  23'397 methods is almost one third of what is allowed by dalvik VM
> for a dex file. So once you app gets a little complex and you want to
> use graphhopper the limit can be reached quite easily. 
>
>
> Now my question is : is there a way to avoid trove in graphhopper for
> example by replaceing trove collections by standard java collections ?
> Or would it be possible to find an alternate lighter (shrinked)
> )version of trove or another collections library. 
> Would there be a huge performace difference ? 
>
>
> Thank you for your help. I'm a bit stuck here. 
>
> Cheers, 
>
> Alex
>
>
>
>
>
> _______________________________________________
> GraphHopper mailing list
> GraphHopper at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/graphhopper


-- 
GraphHopper.com - Fast & Flexible Road Routing

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/graphhopper/attachments/20140503/0e42dcb8/attachment.html>