-
Notifications
You must be signed in to change notification settings - Fork 301
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
_sf_: abyssmal performance on Win Server 2022 #2239
Comments
Without a minimal reproducible example and access to the version of Windows you are complaining about, use of invectives is most unlikely to get you anywhere. Someone else has to be able to demonstrate this claim independently. |
Yes, sorry -- I was more looking for any similar experiences from the community as I'm clueless about what's going on here with my setup. I've attached a sample of the
As for the system on which the script is running, I've included the details below:
I hope it helps fill in the gaps in my previous post. Thanks for any insight. |
No access to any such system. Please create the subset prior to |
I can confirm this issue on Windows 10 with PROJ 9.2.0. In system.time(st_transform(DA16[1:100, ], crs = "EPSG:4326"))
#> user system elapsed
#> 0.25 0.00 0.25
system.time(st_transform(DA16[1:1000, ], crs = "EPSG:4326"))
#> user system elapsed
#> 22.46 0.00 22.48 Session Info
|
The same is for system.time(
gdal_utils("vectortranslate",
"lda_000b16a_e_sample.shp",
"test.gpkg",
options = c("-t_srs", "EPSG:4326",
"-limit", 1000))
)
#> user system elapsed
#> 23.00 0.02 23.02 @bthierry-udm, what PROJ version do you have on macOS and Windows 10 (see |
The Here is the result of the snippet without the pipes and subsetting:
Below, the sessionInfo for the Win Server workstation:
And the MacOS one:
The Win 10 laptop is running on some older version (and is not subjected to the same slow processing as seen in Win Server):
@kadyb Updating the Win 10 laptop to the latest R and sf versions, I can indeed reproduce the issue.
|
So the problem probably is with PROJ 9.2.0. Maybe this issue is related and already fixed. Unfortunately, to update PROJ, we have to wait for the new version of R on Windows. |
Could well be, as the provided dataset has datum NAD83. |
|
With PROJ 9.1.1: sessionInfo()
# R version 4.3.1 (2023-06-16)
# ...
# loaded via a namespace (and not attached):
# [1] compiler_4.3.1
library(sf) # 1.0.14
# Linking to GEOS 3.11.1, GDAL 3.6.4, PROJ 9.1.1; sf_use_s2() is TRUE
DA16 <- st_read('DA16_sample')
# Reading layer `lda_000b16a_e_sample' from data source
# `/home/edzer/Downloads/DA16_sample' using driver `ESRI Shapefile'
# Simple feature collection with 2000 features and 22 fields
# Geometry type: MULTIPOLYGON
# Dimension: XY
# Bounding box: xmin: 7609465 ymin: 1228651 xmax: 9015737 ymax: 2986430
# Projected CRS: PCS_Lambert_Conformal_Conic
system.time(st_transform(DA16[1:100,], 4326))
# user system elapsed
# 0.035 0.008 0.054
system.time(st_transform(DA16[1:1000,], 4326))
# user system elapsed
# 0.238 0.000 0.238
system.time(st_transform(DA16, 4326))
# user system elapsed
# 0.507 0.004 0.512 |
So the analysis in #2239 (comment) was correct, and PROJ for binary package builds should be moved beyond 9.2.0 to avoid the regression. Wrt. #2240 (comment), and that it is a long time to 4.4, should we explore the consequences of updating MXE to PROJ. 9.3.0 and GDAL 3.7.2? |
I ran into this too! Almost impossible to understand what's going on, nor to know where it is coming from. Now that I found the source, I added this to my code. if (sf::sf_extSoftVersion()["PROJ"] == "9.2.0") {
cli::cli_warn("It is not possible to switch crs to 4326 currently. On Windows, only possible with R 4.2 or R 4.4.")
} |
Wrong, only transformation to NAD83 may be affected by taking more time than before or after, results remain correct. Pleade do not jump to conclusions. |
But as I am using also data from Statistics Canada, it is the only format provided. Because I have been affected by #2104, I remember having used st_transform(4326) + sf_simplify and the result was wrong.. |
After an upgrade request in Rtools PROJ now has version 9.3.0 in Rtools 43 https://cran.r-project.org/bin/windows/Rtools/rtools43/news.html |
I have sf, version 1.0-14 running in R v4.3.1 on a workstation configured with Windows Server 2022.
I recently moved one project from my iMac, which is running the exact same sf and R versions, to that workstation and noticed that many if not all sf functions seem to run way slower than on my Mac. One of them is
st_transform
-- see below:Win workstation is equipped with twice the RAM and a SSD, not configured as a virtual server and I was the only logged user. Hence ressource issues are probably not the explanation here.
BTW, the same snippet run on a Win 10 laptop gives timings similar to the Mac. As a side note, running the same kind of operation using PostGIS does not lead to meaningfull time difference between Mac and WinServer.
Any idea why sf is so slow on a Win server compared to desktop OSes ?
The text was updated successfully, but these errors were encountered: