Latest Contributions by MattWilkie1

I believe the lag time related to number of layers is because the GP tool validator inspects each and every one for validity, testing that a) it exists and b) is the specified or necessary data type. This can be bypassed by going direct to an arcpy script, but that's only a time saver in a narrow range of cases. ... View more

Thanks Ian. No, not on the beta programme. I was a few years ago but pulled out because there's too much distance between that and production. I need to support and instruct users on stable, which means I need to be using the same environment as them. Switching between env's is too attention/time costly. ... View more

Eep, prematurely posted. I was about to add "if we all just reply metrics in-thread like this it's not going to be very useable. Is there an option to format and export the metrics as csv?" ... View more

This is very useful, thank you! Now, how should we share and compare metrics? For example on my machine it takes 12.8 seconds to open Pro with no project, and 2.8s to acquire a license. Both feel too long to me, but are they unnusual numbers? ------------------ ArcGIS Pro Metrics ------------------ --- Fixed Metrics --- LicenseTime = 00:00:02.8451996 StartupTime = 00:00:12.7988896 --- StartupDLLCount = 260 CurrentDLLCount = 365 --- StartupLocalDLLCount = 90 CurrentLocalDLLCount = 175 --- StartupMemoryUsage = 342163456 CurrentMemoryUsage = 513839104 --- StartupThreadCount = 57 CurrentThreadCount = 55 --- TotalBlockedTime = 452 TotalHungTime = 15297 TotalPaneConstructTime = 0 TotalTaskTime = 7062 --- CIMReadCounter = 0 CIMUpdateCounter = 0 UICIMReadCounter = 107 UICIMUpdateCounter = 25 --- Named Metrics --- Startup:Initialize_and_process_DAML = 3902 Startup:ShowWindow = 510 Startup:Initialization_complete = 3498 ProjectLoad:InternalOpenProjectAsync = 7219 ... View more

Thank you Kory. It is gratifying to know our concerns are being read, that these aren't plaintiful voices in the wilderness, unheard. This is a marked departure from years past. A form or guideline for submitting performance issues might be a good idea. Though one of the drawbacks with submitting (solely) through a tech support channel is not knowing if one is alone in experiencing a thing. ... View more

I completely agree that's it should be Esri that is collecting, testing, quantifying and fixing performance issues. That we pay a lot of money for tools which should work and work well, to a professional level. However, they aren't doing that measuring and if we wait for them to decide to undertake that we'll be waiting a very, very long time. The fundamental problem is that Esri is a tool builder not a tool user. They do not see the problems or feel the pain because they aren't doing what we are. Therefore we need to communicate that in a way they can a) understand, b) action. A chorus of "this sucks!" might be momentarily cathartic, now we know wer're not alone and others are similarly unhappy too, but it doesn't incite change. Matt who has participated vocerifously in such threads many times since in 1995. ... View more

In my experience individual tools are generally much faster than ArcMap, but it takes longer to get to them and set them up to fire. In general, I find the act of using Pro to be sluggish and occassionally non-responsive for minutes at a time (20-30s is a common daily experience, while minutes is rarer but still happens every week).  From the responses here it's clear that there is a wide variety of performance experiences, and at opposing ends of the spectrum. It would be really good if there were some downloadable toolset that we could all run and collect some quantified data that could be stuffed in a central table somewhere. For example, I have an ArcMap python script  to measure data store performance on our premise. It opens canned maps that load data from a selection of sources (SDE, file-gdb, network share, ...) , exports each to pdf, and saves the times into a CSV. It's not readily shareable because of the dependency on our stucture but the idea is portable. Another lack is that the script is headless, which means it would miss the main part of my Pro frustration, the GUI. However this could be remedied with a self executing AutoHotKey script. GitHub is an obvious and readily available place for "where to get the tool from" as well as "collection of testing recipes".  Care would need to be taken so that only shareable non-private info is collected of course. GitHub could also store the stats but there might be better choices for that. In my opinion it would be better for the community to build this test suite than Esri. The tests would spring from our pain points not theirs, and the data public. It would be great-to-essential if they were active participants though. Ok, so who would head this up? ...unfortunately not me. My development skills are middling and my time for next 6 weeks is fully booked. I can and will be an active contributor though, in spurts here and there. Ping me at [email protected]. ... View more

Oh, okay. That's basically the same thing as what we're doing now -- geotiff's with pyramids -- with a different (albeit more robust) mechanism handling the administration of the sections/tiles. I should make a tile cache of them and see if there's any difference performance wise in our advironment. ... View more

<raises hand>Wait, cache? what cache? how do you build, and then distribute them? I've never seen mention of caches in ArcGIS outside of Server. Clue me in! ... View more

Off-topic: Pro "Arc Map" Equivalency Ideas You Should Vote On!  is a good idea, thanks for putting it together. I have something similar on our intranet. There's no way to comment on the doc, thus the intrusion here. Maybe announce it with a blog post, and link back to the blog post from the doc. ... View more

This sounds useful, but what about just being able to georeference single page pdf's in-situ, without conversion? ... View more

I should also say I'm particularly interested in the mechanics of "not recommended to give Domain Users or Authenticated Users permissions to these registry keys. If this is done, computer functionality will slow to a crawl." On multiple occasions I have spend many days troubleshooting why ArcMap (this/that) and/or Windows itself is unreasonably slow. With this teaser line I'm naturally wondering if mis-aligned registry permissions may have played a role in that. ... View more

Thanks Curtis. I'm familiar with env var to change license level (my scripts). The scenario which prompted this is users not being able to change the License Manager host names. I know that can be done with batch files too but if I ask users to edit batch files or environment variables I'll spend too much my time with supporting how to do that. I'm reluctant to go down that road. 😉 ... View more