Skip to Content.
Sympa Menu

cgal-discuss - Re: [cgal-discuss] Slow Performance when Computing the Minkowski Sum of two Simple Squares

Subject: CGAL users discussion list

List archive

Re: [cgal-discuss] Slow Performance when Computing the Minkowski Sum of two Simple Squares


Chronological Thread 
  • From: Efi Fogel <>
  • To:
  • Subject: Re: [cgal-discuss] Slow Performance when Computing the Minkowski Sum of two Simple Squares
  • Date: Wed, 17 Jan 2024 20:04:07 +0200
  • Authentication-results: mail3-smtp-sop.national.inria.fr; spf=None ; spf=Pass ; spf=None
  • Ironport-data: A9a23:25GQqK3mVHhsd6c6GfbD5XB1kn2cJEfYwER7XKvMYLTBsI5bpzIDn WpKWDiCb6vZNGrxftF1bIu0pBsOvsSAnIJlSAtu3Hw8FHgiRejtVY3IdB+oV8+xBpSeFxw/t 512hv3odp1coqr0/0/1WlTZhSAgk/vOHNIQMcacUghpXwhoVSw9vhxqnu89k+ZAjMOwa++3k YqaT/b3Zhn9hlaYDkpOs/jf8Eo24qyp0N8llgVWic5j7Ae2e0Y9V8p3yZGZdxPQXoRSF+imc OfPpJnRErTxon/Bovv8+lrKWhViroz6ZWBiuVIKM0SWuSWukwRpukoN2FXwXm8M49mBt4gZJ NygLvVcQy9xVkHHsLx1vxW1j0iSlECJkVPKCSHXjCCd86HJW3bmm618KU8YBNAz8chdJE5E3 9IzcAlYO3hvh8ruqF66Yuxlh8BmNdWyeY1G6ikmwjbeAvIrB5vERs0m5/cChGZ21p0IRKiGI ZNJMVKDbzyYC/FLEloZCZw5k+qsrnb6ejxc7lmSoMLb5kCMk1Qgi+O8brI5fPTTd+VNnHedg Fv75n/yGQoxMYW6zmS8pyfEaujnxn6iAN1DStVU7MVCi1KawikfCQYdSECgieKoj1a3HdNZM U0dvCQ0xZXe72SuR9j5GgSk+TuK505EHdVXFOI+5UeGza+8Dxul6nYsQzQZMM4DuuEPGBch+ HWssNnDKxc3iejAIZ6CzYu8oTS3MCkTCGYNYy4YUAcIi+UPRqlj3nojqf4zT8aIYs3JJN3m/ 9ydQMEDa1g7iMcK0+Ci4QmCjWv8/t7GSQk64giRVWWghu+YWGJHT93wgbQ4xa8fRGp8crVnl CZc8yR5xL5WZaxhbATXHI0w8EiBvp5pygH0j191BIUG/D+w4XOldo04yGghfBo1aJdUKWS2O x67VeZtCHl7bCvCgUhfM93ZNijW5fGwfTgYfqmIMIMQOsYtHON51H03NR/Nt4wSrKTcufpiY M/EIJjE4YcyBqNgwz67D+Yb2vlD+8zN7TK7eHwP9Dz+ieD2TCfNF98taQLSBshntv/siFuOq L53aZDaoyizpcWkPUE7B6ZIfQ5URZX6bLiqw/Fqmhmre1M8RDF6W66KntvMueVNxsxoqwsBx VnlMmcw9bY1rSSvxdyiMyg4MOHcTtxkoGglPCchG1+t1jJxKcys9aoTPd9/N7Uu6OUpn7Y+Q ugnavewJK1Fag3G3DABMrj7johpLyqwiSy0YiGKXTkYfrxbfTLvxOPKRAXVyXQxPnKFjvdm+ 7yE/SHHcKUHXDVnXZr3aurw7lafvko9ueNVXmnOKOZ9YE/HrYpgcXTwqtQVIMg8DwrJ6RXH9 gSRADYe/fLspa1s+vb3pKm0laWbOMogIVh7Rk7w8qSTGRTB2Faa0atscbqtbC/McmHZ44Cgb rhl9O79O/g5g1p6iYpwPLJ1x6YY5dG0hbtl4il7PXfMfXK5I6hBJySY4MxxqaF9/L9Vlg+oU Eap+NMBG7GoOtvgIWEBNjgeceWP+vEFqAb8tc1vDh3B2xZ2276bXWF5HRqG0nVdJYQoFrIV+ 74qvcpO5jGvjhYvDM29sRlV0GaxNV0FbbQss8ALIY3sizdz8Gp4X77nNnbU7q2MOvJ2CWt7B h+PhaHHuaZQ+VqaTVo3Ckr2/LR8gbYghUl06WEsdnWzp8r9p/4o3Rdu3yw9YSZLwz5mje9iG GhZGHdkBKeJ/j1XqtBJdDm8Fy1sGC+b1xDU4AYPnjeISUOHa3H8djwhGOeS/XI293BXUShb8 Yq5lkfkc2fOV+Pg0hQiXXVKr6TYcuVw0QnZiuWLLt+gHaRmUQH6g6SrW3UEmyHnDew1mkfDg +tgp8R0VoHWKg8SpPcdJ7SB9LFNVi2BGnNOccth8IwNA2vYXjO4ghqKCkKpf/JyN+74ylC5B +NuN/BweUyHjgjWlQ8iBIkIP7NQt9wq7oBberrUeEg3g4HGpT9t6J/t5izygVEweOpXkOE/F 5jwcgyTGWnBlFpWnG7w9PN/AFSaWuVdRgPA37GSyt4rRrYjq+BndH8g3oSk50u1NBRVxDPKn QfhSZKP8clc59VNpaXOHJ9HJT2IEvLodeHR8AmMo9VENtzOFsHVtjIqkFrsPiUIHL4dR+VIk a+ptfjp1njkp5czaXjSwLOaJplK5OKzfetZCd32J39khhm/WNfgzh8A2mKgI7lLrY95yuy4Y TCnMe2cWMUwWdhP4FF0MQ1lDAc7GaD7SozCtBGNha2AJTZF2DOWMe7902HiaF9qUxMhOrr8L 1TRkOmv7NUJl7Z8LkYIKN8+CqApPWK5f7UtcuDwkjyqDmOIpFemkZm6nDoC7QD7MFW1IPzY0 7nkGCenLA+TvZvWxu53q4Zx5x0bLEhsiNkKI34yxYREtCCYPkUnc8ImLpQ0OrNFmHfT1bb5R g33QkkMNCHfZQlAIDLAuInNfwHGCuI3b4KzYnRj+k6PcC65Cb+RGLYrpG8q/35yfSCl1+29b 80X/nrrJBWq35V1XqAp6+emhft8jObvrp7SFZsRT+Spa/rfPVkL6JClNA9EVCiCCt2U0UuSd TBzSmdDT0W2D0X2FK6MvpKT9A4x5FvSI/cANE9jA+ozf62UyeRBzLv0POSbPngrcpERPLBXL Z/obzLl3o1Vs0D/fYMmvtsohel/Dvfj8g1W6kP8bVV6opxcIVjL8y/PceTjgS3iFMNi/4vhq wSR
  • Ironport-hdrordr: A9a23:AoLyLq9fTmk2CwkzDJBuk+ACI+orL9Y04lQ7vn2ZKCYlD/Bw8v rEoB1173DJYUkqKQgdcLy7UpVoAkmsjaKdmLNhX4tKBTOW3VdAT7sSl7cKoQeAJ8SWzIc06U 4HScZD4bbLYWSS4/yW3OGUeOxQo+Vu3MuT5ds3yR9WPGZXg6UJ1XYcNu7NencGPzWurqBJcq ah2g==
  • Ironport-phdr: A9a23:Q8jq5x00fHLUg0fqsmDO5A0yDhhOgF0UFjAc5pdvsb9SaKPrp82kY BaPo68y0RSQBd2TwskHotSVmpijY1BI2YyGvnEGfc4EfD4+ouJSoTYdBtWYA1bwNv/gYn9yN s1DUFh44yPzahANS47xaFLIv3K98yMZFAnhOgppPOT1HZPZg9iq2+yo9JDffQZFiCCjbb5wL Bi6ohjdutUKjYB/Nqs/1xzFr2dHdOhR2W5mP1WfkQri6Myt5pBj6SNQu/wg985ET6r3erkzQ KJbAjo7LW07/dXnuhbfQwSB4HscSXgWnQFTAwfZ9hH6X4z+vTX8u+FgxSSVJ8z2TbQzWTS/8 6dmTQLjhSkbOzIl9mzcl8p9h79Zrh28vRxy24HbYI+XO/R+cK3Tfs4US3RdUctKTSNNHpmxY pETA+YdP+tVqZT2qVsUrRu5AAmhHOzhyjFJhnTr3aM61OshHh/C3Ac9GN8BrnrUrNT7NKcVX uC60q3IwC7Mb/NTwzj96YzIfgo9rvGLWLJ9aMzcwlQgGA3ZlFufs5DlPy+L2eQXtWiW9+ptW +2hhWM5qgx9vjahytoihIXUhI8Yzl/J+yp6zYooONG1TFJ2bNyqHZdMqi2UOYl7TMMiTmx1u is0xLwLtJ69cSMXxponwBvfZOaGc4iO+h/sSOmRLi18hH5/f7K/nRmy/VChyu36TMm00UxFo jBLktnWsH0Gyh/d6tCfR/dj4kus3SyD2gPT5+1ePEw5lLbXJ4Q8zrMzipYet1nIEzHymEXrl 6+Walsr+vK15eTmY7TpuIeRO5NyhwrjKKohgNa/Dv49MgUWX2iU5+C81Lr78E38WrpKj/k2n rDAsJDGOMgXv6C5DxJW34o/8Rq/ADCm0NMXnXkDMl1JYg6Ij4/sO13WIfD4C+mwg0i0nTt12 /zLOqftD5bNI3TZjbvsfKpx51RBxAcw0dxT/5dUBasAIPL3VE/xrtvYDhohPgOqzebnCdt91 oQRWW2RBq+UK6zSsVqS6eIuJ+mAfpMauDH4K/Q94f7hlmc2mUUBcqmxwZsXdHe4E+x7L0mBe 3rjns8BEXsWvgo5VOHllFKCXiRXZ3qrQq085yo7B567DYfYXYCgm6eB3Se+Hp1OfG9KEFGME XHyd4WFQfgAciySItUy2gECTqWrHo89yQm15ki90KtiNuOS+ysCtJul2sIy/PzWjRh19Dp6C IOW3GiJCm11hWgVXCRl4aZkvEZd1lKHhKhkn+RDR5sU/OJMSg58NJjGzuU8Bcq1QRPEZt7OS VCoRZKtDjg1C94w2NQTeF0uJtO5kxr/0jq2Vr8Ji6SQVttz6bPZx3G3JsBnyn+A2rNmlEgjW sIINGuogel0+AHXQoLIiE6EjL35SaNJ1yHE8CKPzHGFoVpDeA92S6TMG34FNWXMqtGsy03DB 5GpBrkjel9Mx8+MLaRHbvXmiFxHQLHoP9GIMDH5oHu5GRvdnuDEV4HtYWhIhE01aWABmgEXp jOdMBQmQzymuyTYBSBvElTmZwXt9/N/oTW1VBx81BmEOmtm0bf94RsJnbqEUfpG07wFtiAup jFcE1O03taQAN2F9EJ6ZKsJWdom+x9c0H7B8Ql0P5iuNadn01MQcgpwsE7q/xpyA4RE18Mtq SBi1xJ8fISf1l4JbDaExdbwN7nQf3H15wyqYrXK10v21d+X/uIW9K19pQyz5EemEU0t93gh2 N5Qu5eFzrPNCgdaEZf4U0JssgN/u6mfeS4loYXdyXxrN6Cw9D7EwdMgQuU/mF6meJ9EPaWIG RWXcYVSDtWyKOEsh1mibw4VdOFU+qkuOsq6dvyAkKe1NedklTiigCxJ+od4mk6L8iN9TKbP0 fNni7mV0AqJUDjxiH+ut8n2ncZPYjRTVmuzxC74BZJAM7VodNVDAmOvLsurg9Rm0sS1CjgIq Rj6WQtAgZ/xKn/wJxTn0AZd1FoauymikCq8lHlvli0x67GYxGrIyvjjcxwOPihKQnNjhBHiO 9vR7ZhSUU62YgwujBbg61z9wv0Rqap+IW7cTENgcC3/LmUkWay1/OnnAYYH+NYzvCNbXf7pK 12US7D6rBYe+yzmFmpagjs8cnv58oW8lBt8hmWHKX91p3eMYsB8yyDU49nETOJQ1D4LLMVho QHeHUP0f9yg/NHP0ozGrvj7TGW5EJtabSjsy4qE8iq9/2xjRxOlzbi/ndjuEA5y1iGetZEiW CvJohHzb43D2KGzMOYhdU5tTFPx8Mt1HIhin5B43slBnyhHwMzLpTxewT+7OM4Twa/kaXsRW TMHprydqBPo3kFuNDPBxo70UGmc3to0YtC7Zm0M3Sdup8tOCaqS8PlFhX4v+gv+/V+XOKYl2 G5NkahLijZSmewCtQszwz/IB7kTGRIdJinwj1GT6Mj4qqxLZWGpeLz21UxknNnnAqvRx2MUE Hv/ZJomGjd9q8tlN1eZmnD964/jd9TURd0WvxyQ1RzHiqIGTfB53upPnidhNW/n6Dcoxe81i hNj2bm1uYGGLyNm+6fzUVZIczbyYc0U4DTki61Ty92X046YFZJkAjwXXZHsQKHNcnpapbH9O g2JCjF5tmaDFO+VA1qE8Ek/5SGHA9WxOnqQPnVc0dhyWEzXOhlEmA5NOVdy1p8hSlLxmYq4I R8/vGxOoAa/8EcEy/o0ZUejFD2E/0HxNG9yEN/GfVJX9l0QuRmTaJTEqLo1R2YCpvjD5ESMM jDJOVoOVz1YHBzcQQikZOHm5MGcobfCQLPiaaKfO/PW7rUOH/aQmcDwjs0/pWvKboPXeSA8a p9zkktbASIgQ5SfwmpQDXxRz2WXNoaavEvuo3Is6JnurLKzHlqovNXHCqMOY483qlbm3OHab b7W3GEgdlM6ntsN3SOakuFBmgNCzXg/LX/1Vu1R/S/VEPCKw/ERVUVKLXgpcpMPtvN0yABJP YSzZsrd8Ll+g7Z1Dl5EUQekgcS1fYkRJHn7MlrbBUGNPbDAJDvRwsixb7nuAbtXxP5ZsRG9o 1P5WwfqIyiDmj/1VhuuLfAEjSeVOwZbsZ28dRAlAHbqTdbvYBm2eNFtijh+zboxj3LMfWkSV Fo0O1tKtaGV5DhEj+9XHmVA6j98MbDBlX/Jt6/XLZEZtfYtCSNx1qpb7Hk817pJ/XRESfhyy 06w5pZlp1CrlPXKyyIyCkIf7GYWwtvV5QM7af2Kk/sIEWzJ9x8M82iKXhEDpt8+T8bqp7gV0 d/X0qT6NDZF9dvQu8oaHcndbsydYx9DeVLkHiDZCAwdQHulL2ba0gZQnvCc8XKYqrA1r5Htn NwFTboRBzlXXrsKT19oGtAPOsI9RjQ/jbuSl9IF/1K7pRjVAdxG59XJD6LKR/roLzmdgP9PY B5CktaaZcwDc4b83UJlcFxzmo/HTlHRUd56qSpkdgYooU9J/RCWq0U83kvkbkWm53pBTZZcc TY5jwJ/ZaIm8zK+uj/fx3LPrSo01VAtwJDr2GDJNjH2K6i0UMddDC+m7yAM
  • Ironport-sdr: 65a816a5_MX46glBNuMJRrRE26WRh+Q5hmu1ifYHDwqrxSSVYmOJCEJT yEFqjaIvVVKnmTw8b1I/dY0HkWmnrmuEnE2dxhA==

The performance hit is due to the overhead handling of non-convex polygons.
When handling non-convex polygons this overhead becomes negligible.
So, the solution is to get rid of the overhead for convex polygons, and possibly optimize this overhead for non-convex polygons.
   ____  _        ____             _
  /_____/_) o    /__________  __  //
 (____ (   (    (    (_/ (_/-(-'_(/
                         _/




On Wed, 17 Jan 2024 at 19:22, Andreas Fabri <> wrote:

Hi Valentin,

Are your polygons always convex?

Best,

Andreas

On 1/10/2024 10:27 PM, Valentin Pi ( via cgal-discuss Mailing List) wrote:

Hi Efi,

Thank you very much for taking the time. I am glad to seemingly have discovered some unnecessary overhead. I have tried the patch and your snippet, as well as averaged the runtime over 10000 samples. For some reason I now have ~400µs instead of 200µs for the first Minkowski sum, and then the runtime gets quickly down to about 10µs with a i5-1135G7 2.40GHz processor on my laptop. Since I suspected that this is due to caching or some other system effects, I have now randomized the triangles (and renamed them to triangles in the code, sorry for possible confusion) and introduced a delay between each step of the loop. This gives the following source for main.cpp.

#include <CGAL/Polygon_2.h>
#include <CGAL/Polygon_convex_decomposition_2.h>
#include <CGAL/Polygon_nop_decomposition_2.h>
#include <CGAL/Polygon_triangulation_decomposition_2.h>
#include <CGAL/minkowski_sum_2.h>
#include <CGAL/version_macros.h>

#include <chrono>
#include <iostream>
#include <random>
#include <thread>
#include <vector>

typedef CGAL::Exact_predicates_exact_constructions_kernel Kernel;
typedef CGAL::Point_2<Kernel> Point;
typedef CGAL::Polygon_2<Kernel> Polygon;
typedef CGAL::Polygon_with_holes_2<Kernel> Polygon_with_holes;

using Container = std::vector<Point>;
using Arr_segment_traits = CGAL::Arr_segment_traits_2<Kernel>;
using Traits = CGAL::Gps_segment_traits_2<Kernel, Container, Arr_segment_traits>;

int main(int argc, char** argv) {
    using std::vector;
    using std::chrono::high_resolution_clock;
    using namespace std::chrono_literals;

    std::cout << CGAL_VERSION_STR << std::endl;

    std::default_random_engine gen;
    std::uniform_int_distribution<uint64_t> dist(0, 10000);
    auto rand_coord = std::bind(dist, gen);
    Traits traits;
    size_t acc = 0;
    size_t n = 1000;
    for (int i = 0; i < n; i++) {
        Polygon triangle_1;
        Polygon triangle_2;
        while (true) {
            vector triangle_1_points({Point(rand_coord(), rand_coord()), Point(rand_coord(), rand_coord()),
                                      Point(rand_coord(), rand_coord())});
            vector triangle_2_points({Point(rand_coord(), rand_coord()), Point(rand_coord(), rand_coord()),
                                      Point(rand_coord(), rand_coord())});
            triangle_1 = Polygon(triangle_1_points.begin(), triangle_1_points.end());
            triangle_2 = Polygon(triangle_2_points.begin(), triangle_2_points.end());
            if (triangle_1.is_clockwise_oriented()) {
                triangle_1.reverse_orientation();
            }
            if (triangle_2.is_clockwise_oriented()) {
                triangle_2.reverse_orientation();
            }
            if (triangle_1.is_simple() && triangle_2.is_simple()) {
                break;
            }
        }
        auto t1 = high_resolution_clock::now();
        Polygon_with_holes result =
            CGAL::minkowski_sum_2(triangle_1, triangle_2, CGAL::Polygon_nop_decomposition_2<Kernel>(), traits);
        auto t2 = high_resolution_clock::now();
        std::cout << std::chrono::duration_cast<std::chrono::microseconds>(t2 - t1).count() << "µs" << std::endl;
        acc += std::chrono::duration_cast<std::chrono::microseconds>(t2 - t1).count();
        if (i == 0) {
            std::cout << acc << "µs" << std::endl;
        }
        std::this_thread::sleep_for(1ms);
    }
    const size_t avg = acc / n;
    std::cout << avg << "µs" << std::endl;

    return EXIT_SUCCESS;
}


Running this, I get about 600µs for the first Minkowski sum on the most recent branch with the patch you provided me, as well as about 150µs on average for each Minkowski sum. In our main project we get about 300µs for each Minkowski sum. I suspect that allocations are slowing down the Minkowski sum significantly, but I cannot prove it.

Best
Valentin

Am 10.01.24 um 13:34 schrieb Efi Fogel ( via cgal-discuss Mailing List):
Hi Valentin,

I've decided to look into it, cause the timings seemed odd, and I found a few things.

I'm running an i7 core clocked at 2.20GHz:
cat /proc/cpuinfo  | grep 'name'| uniq
model name : Intel(R) Core(TM) i7-2720QM CPU @ 2.20GHz

I changed the single call to a loop and added the traits parameter.
I get ~20us on average on my machine per minkowski sum.
However, even with this I wasn't satisfied.
It turns out that there is some overhead that consumes some unexplained significant amount of time.
Attached is a patch that avoids (some of) the overhead.
It applies to 2 files:
modified:   Minkowski_sum_2/include/CGAL/Minkowski_sum_2/Minkowski_sum_decomp_2.h
modified:   Minkowski_sum_2/include/CGAL/minkowski_sum_2.h
It is based on the most recent version, so if the automatic application of the patch fails for you, apply it manually. It is rather simple.
Also, make sure to use the following snippet:

using Kernel = CGAL::Exact_predicates_exact_constructions_kernel;
using Point = CGAL::Point_2<Kernel>;
using Container = std::vector<Point>;

using Arr_segment_traits = CGAL::Arr_segment_traits_2<Kernel>;
using Traits = CGAL::Gps_segment_traits_2<Kernel, Container, Arr_segment_traits>;
using Nop = CGAL::Polygon_nop_decomposition_2<Kernel, Container>;
Traits traits;
CGAL::minkowski_sum_by_decomposition_2(square_1, square_2, nop, traits);

which knocks out almost ~2/3 of the computation time, and I get ~7us.

Naturally, I'll continue to investigate the issue and fix the code base.

Best,
Efi
   ____  _        ____             _
  /_____/_) o    /__________  __  //
 (____ (   (    (    (_/ (_/-(-'_(/
                         _/




On Tue, 9 Jan 2024 at 19:22, Valentin Pi <> wrote:

You are right, I didn't try that yet. This cuts about 25µs of the runtime to about 175µs.

Am 09.01.24 um 15:57 schrieb Efi Fogel ( via cgal-discuss Mailing List):
If so, then use the decomposition Minkowski-sum method, with a nop decomposition operation; see https://doc.cgal.org/latest/Minkowski_sum_2/classCGAL_1_1Polygon__nop__decomposition__2.html

Try something like this:

Polygon_with_holes result = CGAL::minkowski_sum_2(square_1, square_2, CGAL::Polygon_nop_decomposition_2<Kernel>());

   ____  _        ____             _
  /_____/_) o    /__________  __  //
 (____ (   (    (    (_/ (_/-(-'_(/
                         _/




On Tue, 9 Jan 2024 at 12:58, Valentin Pi <> wrote:

Yes, I just checked. Would be surprising to me if not, since there are unique coordinates for each triangle in the code.

Am 09.01.24 um 11:31 schrieb Efi Fogel ( via cgal-discuss Mailing List):
Do you have any guarantee about the input polygons being convex?
   ____  _        ____             _
  /_____/_) o    /__________  __  //
 (____ (   (    (    (_/ (_/-(-'_(/
                         _/




On Tue, 9 Jan 2024 at 10:41, Valentin Pi <> wrote:

Thanks for the quick reply.
1. I have now tried a couple of versions, but only from the header-only versions. Denoted with the tag names each, I give the following table of observed average times. The numbers I gave initially were with v5.6, as already said.

Release tag - Observed average runtime
6.0-dev [1] - 200µs
       v5.6 - 200µs
       v5.5 - 185µs
       v5.4 - 275µs
       v5.3 - 300µs
       v5.2 - 275µs
       v5.1 - 250µs

[1] The current version at commit a15af8ef645c414956640348d036609b9a0a5c38.


I do not detect a degradation with any particular version, except for a slight jump from 275µs to 185µs between v5.4 and v5.5. For the complexity of the problem anything over a couple of µs is too much for our application, so all of these times are problematic for us. I could try older versions if you think it would make a difference.
2. I have tried convolution (in v5.6) and it gives about the same time.

Am 09.01.24 um 08:10 schrieb Efi Fogel ( via cgal-discuss Mailing List):
1. Have you measured it with a different version? I mean, are you detecting a degradation?
2. Have you tried other implemented alg, or at least other decomposition methods?
The call without a decomposition method invokes the partial-convolution method, which is the most efficient in most cases:
CGAL::minkowski_sum_2(square_1, square_2);
   ____  _        ____             _
  /_____/_) o    /__________  __  //
 (____ (   (    (    (_/ (_/-(-'_(/
                         _/




On Tue, 9 Jan 2024 at 01:09, Valentin Pi <> wrote:

Hello everyone,

I hope this issue fits this list. In our current project we need to compute a lot of small Minkowski sums, and I wanted to ask if someone could please give me some help in speeding that process up. The following CGAL program computing the Minkowski sum of two small polygons demonstrates the problem.

main.cpp:

#include <CGAL/Polygon_2.h>
#include <CGAL/Polygon_convex_decomposition_2.h>
#include <CGAL/Polygon_triangulation_decomposition_2.h>
#include <CGAL/minkowski_sum_2.h>

#include <chrono>
#include <iostream>
#include <vector>

typedef CGAL::Exact_predicates_exact_constructions_kernel Kernel;
typedef CGAL::Point_2<Kernel> Point;
typedef CGAL::Polygon_2<Kernel> Polygon;
typedef CGAL::Polygon_with_holes_2<Kernel> Polygon_with_holes;

int main(int argc, char** argv) {
    using std::vector;
    using std::chrono::high_resolution_clock;

    vector square_1_points({Point(0, 0), Point(4, 0), Point(4, 4)});
    vector square_2_points({Point(2, 1), Point(3, 1), Point(3, 2)});
    Polygon square_1(square_1_points.begin(), square_1_points.end());
    Polygon square_2(square_2_points.begin(), square_2_points.end());
    auto t1 = high_resolution_clock::now();
    Polygon_with_holes result =
        CGAL::minkowski_sum_2(square_1, square_2, CGAL::Hertel_Mehlhorn_convex_decomposition_2<Kernel>());
    auto t2 = high_resolution_clock::now();
    std::cout << std::chrono::duration_cast<std::chrono::microseconds>(t2 - t1).count() << "µs" << std::endl;

    return EXIT_SUCCESS;
}


CMakeLists.txt:

cmake_minimum_required(VERSION 3.19.1)
# SotMS: "Slowness of the Minkowski Sum"
project(sotms)
find_package(CGAL 5.6 REQUIRED COMPONENTS Core)

add_compile_options(-O2)
set(CMAKE_BUILD_TYPE Release)

add_executable(sotms src/main.cpp)
target_link_libraries(sotms CGAL::CGAL_Core)


Compilation and execution (move the main.cpp in a folder named src and the CMakeLists.txt in a folder above before):

$ cd src
$ cmake ..
$ make -j
$ ./
sotms

I have observed the following:
1. The execution times for CGAL::minkowski_sum_2 for the above program lie around 200µs. This gives room for about 5000 Minkowski sums per second, which is not a lot, given the complexity of the above problem.
2. In the main project we usually have runtimes of about 1500µs. In some executions of our main project program the runtime jumps to several seconds up to minutes, but I cannot reproduce that well yet.
3. Repeating the above code (by introducing a for loop wrapping around the lines 23-27) yields runtimes of about 20µs, but I think this is due to optimizations, but 20µs is still too much.
4. Disabling optimizations (-O0) gives runtimes of about 1000µs for the first Minkowski sum, which then upon repetition of the computation breaks down to about 200µs again for some reason.

I have already tried changing the kernel to an inexact kernel, which still gives poor performance and does not suit our use case, since it often crashes. I am on an Arch Linux (x64) laptop, CGAL is compiled with GMP and MPFR, everything is up to date. The CGAL version in the Arch repository is 5.6

Best
Valentin


--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss


--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss

-- 
Andreas Fabri, PhD
Chief Officer, GeometryFactory
Editor, The CGAL Project

--
You are currently subscribed to cgal-discuss.
To unsubscribe or access the archives, go to
https://sympa.inria.fr/sympa/info/cgal-discuss




Archive powered by MHonArc 2.6.19+.

Top of Page