URLConnection / Xojo.Net.HTTPSocket speed slowdown and higher CPU usage

Just FYI:
Since 2018r4 the new URLConnection and the already existing Xojo.Net.HTTPSocket are much slower and have a much higher CPU usage.
The speed decreases about 95 %.
The CPU usage increases about 200 %.


Unfortunately this is a real showstopper for us and we hope for a point release with a bug fix coming soon.

This is a major bumb again. 2018r4 had it’s issues and now they seem to come back

We’d love to make benefit of this huge improvement:

Unfortunately we can’t with this poor performance of Xojo.Net.HTTPSocket and URLConnection.

Looks like it’s fixed now in 2019r1.1

Please note that on macOS, URLConnection has a higher CPU use than HTTPSocket - see case <https://xojo.com/issue/55709> which is private at the moment, but I’ll ask about making it public.

Unfortunately there’s still a bug with URLConnection which is hard crashing the app and increasing CPU usage extremely:

I can confirm this behavior.

The difference between your project and my project (see <https://xojo.com/issue/55709> ) is that you are calling

URLConnection.Send(“GET”, url)

and in my project I’m using

URLConnection.Send(“GET”, url, folderItem)

So the bug seems to be “URLConnection.Send, called without a folderItem, locks up the app”

And a workaround seems to be: provide a folderItem.

[quote=439232:@Stefan Adelsberger]Unfortunately there’s still a bug with URLConnection which is hard crashing the app and increasing CPU usage extremely:

So far, we haven’t been able to reproduce this here. Has anyone other than Stefan or Michael seen this?

Well ask the reporter if he is catching the exceptions of the class. Cause it’t know to hard crash if one doesn’t use a try cacht around those type of http sockets. I havn’t seen it yet and use them alot. If i notice something let it know.

What about @Wayne Golding ?

I had to be very careful getting those screen shots as if I left it too long my machine needed rebooting i.e. required finger on the power button as there was no other response available.

[quote=441800:@Stefan Adelsberger]What about @Wayne Golding ?

It does sound like that could be the same problem. We just need a project that lets us see the problem here. I understand why Wayne can’t share his project though.

Hi Jason, are you talking about Case 55849? (A windows app locks up when downloading a big file using URLConnection.Send(“GET”, url) without a folderItem?

Easy to reproduce : download this demo file (if you would please re-open 55849 I’ll add it there):

I’m a little confused because the last note on case 55849 talks about failing to reproduce it on macOS - but it’s a Windows bug!

Thanks Michael. Yeah, I added the FWIW to the macOS comment to make it a just in case this helps comment :slight_smile:

So far, we haven’t been able to reproduce the problem here (on Windows) but we will try the project that you just posted.

I’m testing a x64 windows build on a Windows 10 (1903) VM running in Fusion 11.1.0 on macOS 10.14.5. I see the problem both as a built 64 bit exe as well as when remote debugging from mac to Windows. When i click the button, the app starts using 50% CPU (on a 4 cpu system) and gets the “Not Responding” message from windows OS. My router shows little or no data is being downloaded. Letting it run for 10+ minutes - it never recovers.

A 64 bit mac build of the same project fails (it throws an error due to app transport security). But if you add an info.plist file to the project that contains:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
	  <!-- Include to allow all connections; avoid if possible -->

Then it does work. On MacOS it uses more CPU than I’d like (50% ish) but that’s probably a different issue reported here: <https://xojo.com/issue/55709>

Here’s version 4 which has the Info.plist and explicit 64 bit build settings for both platforms - otherwise identical to v 3.


Thanks for everyone’s help on this - we have verified the case. We see the problem when testing this project: