[
https://issues.apache.org/jira/browse/SEDONA-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17642785#comment-17642785
]
Jia Yu commented on SEDONA-206:
-------------------------------
[~swakai] Hi Sachio, can you look into this?
> Performance regression of ST_Transform in 1.3.0-incubating
> ----------------------------------------------------------
>
> Key: SEDONA-206
> URL: https://issues.apache.org/jira/browse/SEDONA-206
> Project: Apache Sedona
> Issue Type: Bug
> Reporter: Kristin Cowalcijk
> Priority: Major
> Fix For: 1.3.0
>
> Attachments: image-2022-12-02-18-55-39-236.png
>
>
> The performance of ST_Transform drastically degraded since 1.3.0. This is the
> flamegraph of an executor node when running queries like this:
> {code:java}
> SELECT COUNT(1) FROM ms_buildings WHERE
> ST_Transform(ST_FlipCoordinates(geom), 'epsg:4326', 'epsg:3857') is not NULL
> {code}
> !image-2022-12-02-18-55-39-236.png|width=1194,height=525!
> The performance regression is caused by the introduction of custom CRS
> support. As we can see, most of the time was spent by exception handlers in
> geotools-referencing module. It is a very common use case to specify a well
> known CRS when calling ST_Transform, and we don't want to suffer from such a
> performance hit when doing that. One approach to fix this problem is to
> detect if the CRS string "looks like" a well known CRS by pattern matching
> before calling the expensive {{{}CRS.parseWKT{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
