On 16.01.2010 21:25, Marko Mäkelä wrote:
Hi Felix,

On Sat, Jan 16, 2010 at 09:02:05PM +0100, Felix Hartmann wrote:

On 16.01.2010 20:59, Marko Mäkelä wrote:
+natural ~ 'wetland\|marsh\|mud' [0x51 resolution 20]

Is there a performance increase (or maybe memory usage decrease) vs:
natural=wetland | natural=marsh | natural=mud [0x51 resolution 20]

????
You're right, I should have timed it.  Sorry, I do not know how to
measure memory usage, but I would not expect any significant difference
there.

I tried the attached optimizations to the default style.  Without the
optimizations, it took this long to compile my three tiles of Finland:

real    3m53.333s
user    4m23.332s
sys     0m7.752s

With the style optimized with top-level regexp matches, the compilation
is very slightly faster:

real    3m50.705s
user    4m21.924s
sys     0m7.744s

Note that I had the Ondemand CPU frequency scaling governor enabled.

For some reason, the generated maps are of different size:

-rw-r--r-- 1 marko marko 45475840 16.1. 22:17 gmapsupp.img
-rw-r--r-- 1 marko marko 45423616 16.1. 22:12 gmapsupp-relop.img

I did not investigate this difference yet?

Can you give it a spin on your system?
okay, I changed my whole polygons file to using your notation wherever possible, and ended up 6 minutes 10 seconds instead of 6 minutes 11 seconds for a compilation of the Netherlands, so I cannot see any speed difference. Retried on Italy and saved about 3% of time. However I also lost some polygons, so something definitely does not work with your patch!!!!


I lost all of the following
new:
place ~ 'town\|suburb\village' [0x03 resolution 21]
old:
place=suburb | place=town | place=village [0x03 resolution 21]


I am already using the "final" patch by wanmil on trunk branch.

...........................


Your testing could well be different because you were putting two lines into one like
key1=123
key1=456

whereas I changed from
key1=123 | key1=456

I did not however also that the maps rendered became smaller. I'm still trying to find out the differences.
Best regards,

        Marko

_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Reply via email to