Slow carto layers #1941
Comments
|
Great work for finding this out! |
|
I can confirm the explosion in run time. It's 20 seconds on my system. This is all before touching any database, right? The most surprising one I find text-line. The output of text-line in the XML is also extremely long, and that does not seem to make sense given the CartoCSS. That's something we must look at. The good news is that there are also many layers that take 0 or 1 ms so that suggest improvement is possible. |
|
At least #1944 is an easy win... |
This improves gravitystorm#1941. Carto processing is now overall about 20% faster on my system.
This is likely similar for text-poly. So the landuse statements seem to account for a large portion of the parse time. |
|
|
This improves gravitystorm#1941. Carto processing is now overall about 20% faster on my system.
|
Do we consider this problem to be resolved? In my setup compilation time of a current master branch takes almost 14 s: My 3-digit times: are comparable with those reported by @pnorman: |
If we're back up to those times then no, it's still a big problem |
|
👍. However, it might be possible to fix this on the carto side? I cannot imagine the operations we need to do are so complicated that it really need to take so long. |
|
Using the same system as before, compile time is up to 10s. The slow layers are the same as @kocio-pl got, although my system is generally faster. This is with If I go back to v2.38.0 from early 2016 (after this issue), it's about 25% faster, same CartoCSS version. |
It's a big relief for me that all my changes to carto apparently didn't have a significant negative impact on performance.
Yes, partly. carto is a slow beast and openstreetmap-carto is a very complex style. But there has already been some work done regarding performance, see e.g. mapbox/carto#469. I also have done some profiling lately on carto and the biggest impact have the filter and the style inheritance subsystems. I have been working on doing some improvements to the language so that we have to write less rules. I probably have to rewrite the inheritance subsystem from scratch anyway so I hopefully will tackle some performance topics with that. I also plan to do some fundamental changes to the filter system to use more possibilities of Mapnik. All that should be part of carto 1.0. If you want to have a look at what has already been done see https://github.com/mapbox/carto/blob/master/CHANGELOG.md. |
|
Here are some quick diagrams. Normally I do at least 3 consecutive samples for each data point and average it out, but this time I did only 1 sample per data point. (Absolute parse time values are quite meaningless since they are machine dependent.)
Actually, 0.18.1 seems to be the fastest carto version of the last time. master is slower, but still faster as versions before 0.18. As for osm-carto parse times have gone up with 2.43.0. |
|
I don't think compilation time is too important, because it's done only once in a while. Rendering tiles and database reading is what takes the most computing power, because it's much more frequent action, so we should really watch it. Even when editing style, I usually run Kosmtik when I've made most of the changes and make just a few fixes when something is wrong, so still XML compilation time is not a visible problem for me. Thinking, discussing, managing issues and importing data are the biggest time consuming things for me. However if we care for a compilation time, CartoCSS could probably transform only these files (or only code lines?), which have been changed. For a typical patch it could be only a fraction of the entire style. |
|
Compilation time is not important in production, but it is very important when developing. It takes about 30s to compile on my machine, which really makes it much harder to check some quick ideas. |
When I'm coding the compilation is by far the slowest part in seeing what my changes have done. That's something I've noticed with my other style work, it's much easier to try stuff out in styles that take 1-2s. |
|
OK, looks like we have different patterns, but of course I would be glad if it takes much less time to reload style. What do you think about partial compiling and caching results then? I guess 1-2s times are very likely with this approach. The main question is if CartoCSS team would like to take care of it. |
|
Quick remark here: how much slow compilation affects development work depends a lot on the work style and the background of the developer. A lot of people with a design background rather than a programming background (which is a group we should really try to encourage to participate here) have grown up and learned their trade almost exclusively with interactive tools and tend to be extremely annoyed with waiting times imposed by these tools. I tend to notice this quite strongly because with a long time POV-Ray background i have grown up and learned with the exact opposite type of tool. So with CartoCSS i never consciously noticed the compile time as an issue until it was mentioned here. This seemed perfectly normal and frankly 30 seconds is not even remotely enough to get yourself a cup of tea... Long story short: This should be a point of concern independent if you are personally bothered by it because it strongly affects how attractive the whole ecosystem is for various people. But it should also be clear that there is no such thing as slow and fast in absolute terms. |
Unfortunately I think that this is incompatible with how CartoCSS parsing currently works and therefore is not possible.
I have to tell you that there is no team. There is only me. :) |
|
sent from a phone
On 13. Jul 2017, at 21:48, Christoph Hormann ***@***.***> wrote:
A lot of people with a design background rather than a programming background (which is a group we should really try to encourage to participate here) have grown up and learned their trade almost exclusively with interactive tools and tend to be extremely annoyed with waiting times imposed by these tools.
designers are normally used to make mockups to find the combination of colors, widths, fonts, etc. which can be made with any standard tool like inkscape, gimp or their commercial counterparts like ps or ai. Once you know what you want it is relatively quick to codify these changes (e.g. by modifying a suitable template like osm carto), and the 30 seconds compilation time are neglectable until now. Admittedly they come into play at this time, when it comes to fine tuning the map
|
|
@nebulon42 : From what I understand, you're the only |
Let's say that I'm the only one that has commited to carto in a year or so with one little exception (which was in error and that was reverted later on).
Yes. Performance was not my main concern. I focused on fixing bugs and giving carto a bit more flexibility that should help avoiding that it becomes obsolete too quickly. But performance is a hard task (at least for me) and carto is a complex library.
Yes. I found that roughly 12% of the time was spend with evaluating filters and inheriting style definitions. To be able to finally solve mapbox/carto#461 I wanted to rewrite the inheriting part from scratch. I hoped that I would be able to tackle some performance questions with it. Help is always appreciated. Let's continue at mapbox/carto#483. I will update that with some information I already have found. |
|
Just for info, something that I noticed when compiling OSM carto today. On a particular development system, this style consistently takes about a minute to compile, for example: For comparison https://github.com/SomeoneElseOSM/openstreetmap-carto-AJT (which is based on where this style was as of 2014) consistently takes around 19 seconds, for example: The resulting mapnik.xml from this style is larger (45390 rather than 34610 lines), but it's not 3 times larger. In both cases I'm using "carto 0.18.2". |
|
#2869 will help with the compilation time of the roads layers, when I get back to it, but won't do anything to the text or amenity layers |
|
Current numbers are landcover:251ms total time is 9s Looking at the text-point XML, I see a few odd things
|
We've hit 30 seconds to compile the stylesheet with
carto. This negatively impacts the development experience, since it means you have to wait much longer to see any changes you makecartohas a benchmark mode. With a bit of grep (./node_modules/carto/bin/carto -b project.mml 2>&1 | egrep -B1 'Inheritance time: [[:digit:]]{3,}ms') and some manual cleanup, we can find the slow layersMy system is about twice as fast as Travis, so only takes 15s. These layers are 10 of those seconds.
Edit: Updated. Total time is now 8s on my system.
The text was updated successfully, but these errors were encountered: