IE8 QueryTask getting the 'Script Running Slowly' message

[AlistairDorman-Smith]

Hi

I have a problem with IE8 performance with running a queryTask.

I've searched the forum for similar answers but all the similar threads seem to relate to showing too many points. I'm only working with 695 points, and my query task is only trying to show points within a certain geometry.

In IE8, I get the "script is running slowly" dialog box when the queryTask is run - the script still runs fine if you say continue, but it is very slow.

It's obviously a performance issue, and IE8 is known for a slow JS engine, but I have no idea where the problem is. Simplified geometries have been experimented with, in case that was an issue. In general terms the problem only occurs with larger areas (suggesting larger geometries or complex lines) are the problem, but this isn't always true when you rank each region by size and then click through sequentially.

http://naei.defra.gov.uk/data/local-authority-co2-map
If you click on the link above, and select a region, it does two queries - one to get the layer information, and the second (which is causing the problems) to get the points within the selected region.

If I disable the "execute" function of the queryTask then it runs fine so it's definitely something related to the queryTask itself.

Works fine in IE9 plus modern browsers.

Grateful for any help you can give.
Thanks

[AlistairDorman-Smith]

Following some additional testing, it appears the problem is when there's a complex geography that is being passed into the query task.

Should there be an issue for IE8, handling complex geographies for query tasks? It would seem to be quite a basic bit of functionality for any browser to do?

Grateful for any thoughts!

[derekswingley1 · Accepted solution]

Following some additional testing, it appears the problem is when there's a complex geography that is being passed into the query task.

I would guess that it's a complex geometry being returned by a queryTask.

Looking at your app, clicking a polygon (Northumberland, for instance), causes ~1.2MB of JSON to be pushed to the client. This is almost certainly what is bogging down IE.

You said you'd experimented with generalized geometries. Can you elaborate on what you've done?

My recommended solution would be to use maxAllowableOffset to have the geometry generalized server side before being sent to the client. This will result in a faster response from the server. A little extra work is done server side but less data is sent to the client. Since the majority of time for the request is spent downloading data and parsing data, sending less data to the client is where you'll see the biggest performance improvement (even in browses that handle this volume of data easily, you should see better performance as it will take less time to download the data from the server).

Here's a simple example app showing the benefits of using maxAllowableOffset with polygon data:  http://servicesbeta.esri.com/demos/graphics-performance/polys.html

That app is linked from our Determining Limits for Map Graphics help topic which I would recommend reading. Feature layer best practices is recommended reading as well.

[AlistairDorman-Smith]

Hi Derek

That's a great help, thank you!

The generalised geometries we had experimented with before your help, was fairly simple simplification of the regions in desktop ArcGIS, before publishing. We found it was taking significant simplfications to get them working in IE8.

I've looked up maxAllowableOffset using the various links you pointed me at, and this does seem to work very well and speed up the application for all browsers, not just IE8.

Because of the on-the-fly simplfication it is doing, there is still a chance that
a) the slow script message could appear - but greatly reduced from the likelihood before
b) the query task for the points could get a geometry which is too simplified (we're basing on zoom level as per the example on the ESRI documentation)

But overall, we're impressed with the difference it makes. We're currently getting other team members to review the solution before updating the website.

Many thanks

[derekswingley1]

That's a great help, thank you!

Happy to help!

Because of the on-the-fly simplfication it is doing, there is still a chance that
a) the slow script message could appear - but greatly reduced from the likelihood before
b) the query task for the points could get a geometry which is too simplified (we're basing on zoom level as per the example on the ESRI documentation)

I think you're misunderstanding where the simplification happens and what causes the slow script error in IE. The simplification happens server side. Instead of the server trying to push one MB of geometry to the client, the geometry is simplified and usually reduced to no more than 100 KB or so (usually even less if you're using the settings we recommend). The slow script error is caused in IE by trying to parse large amounts of JSON. This error can be prevented by sending less data to the client, which is why we recommend using simplified geometries.

[AlistairDorman-Smith]

Thanks for your further explanation, really useful to learn how this can help large geometries!

[BrettGreenfield__DNR_]

My recommended solution would be to use maxAllowableOffset to have the geometry generalized server side before being sent to the client. This will result in a faster response from the server. A little extra work is done server side but less data is sent to the client. Since the majority of time for the request is spent downloading data and parsing data, sending less data to the client is where you'll see the biggest performance improvement (even in browses that handle this volume of data easily, you should see better performance as it will take less time to download the data from the server).

I've seen the use of a max offset recommended a lot on forums, but according to one of the links you provided (http://help.arcgis.com/en/webapi/javascript/arcgis/jshelp/#best_practices_feature_layers) layers in ONDEMAND mode automatically set a maxAllowableOffset.  I know in certain instances one can't use ONDEMAND mode (ie for a map I'm making that requires a layer be added in selection mode); but otherwise, is there a reason to manually set the max offset as opposed to just setting the layer to ONDEMAND mode?