Xojo Workers

Xojo 2020 R2 introduced the Worker class.  The Worker is Xojo’s way to use more cores and process data faster.  This is important because the Xojo thread class is cooperative meaning that it runs on the main thread, the same one as your application, and thus shares processor time of a single core.

Why do we use threads in the first place?  Generally it’s to do a lengthy process and you don’t want the user interface to lock up.  There’s nothing more irritating from a user perspective than to have your app do nothing for a few minutes as it chugs through something.  Threads prevent this but there’s a tradeoff using them because it means the overall time it takes to do the processing is longer.  So while the app remains responsive to the user it takes longer for the processing to complete.

So the Worker class is Xojo’s attempt at multi-processing.  The Worker class actually creates a console application that is placed in the application bundle/package and handles all the work of spawning the process and passing information back and forth.

I spent some time this week banging on the two Xojo Worker examples in both Mac and Windows and found some mixed and complex results.  My quick and dirty response about Workers and how good they are is: ‘it depends’.  Let’s start talking about the examples.

My first attempt was taking the Xojo example project PictureResizer and taking it through its paces.  I tested a folder with 1071 png and jpg files.  In all tests I used compiled applications because attempting this in debug results in the Workers using threads (more on this later).  For my workers I allowed 4 cores and up to 90% core usage to stress it out.  I used my 2015 MacBookPro that’s been BootCamped to use the exact same hardware.  MacOS side is using Catalina and Windows is using Windows 10 64-bit.

My initial results were this:

Mac:  274 seconds

Win:  115 seconds

My first question was why Windows was so much faster.  So instead of using Picture.Open I switched to reading the file in via BinaryStream and then using Picture.FromData.

Mac:  182 seconds

Win:  106 seconds

Better but still quite a bit different.  I suspect that Mac console apps are using a much slower Picture library than desktop.  So I then created a thread (using default settings) and found the following:

Threads:

Mac Picture.Open:  196 seconds

Mac Binary Stream:  200 seconds

Win Picture.Open:  124 seconds

Win Binary Stream:  205 seconds

I find it surprising that Picture.Open is considerably faster on Windows than Mac.  But I was still not satisfied with this result as it seems like Workers aren’t working as expected (pun intended).  So I created a new version and passed in 20 files at a time to the Worker.

Mac Picture.Open:  196 seconds

Mac Binary Stream:  176 seconds

Win Picture.Open:  115 seconds (no difference)

Win Binary Stream:  106 seconds (no difference)

So this says to me that the example is flawed.  Only processing one picture at a time isn’t very efficient.  There is some overhead to start a Xojo console application and it seems that on macOS it’s significant enough to barely make it better than using a thread.

For test two I took the WordCount example and modified it to be able to do the same processing from a thread as well as the Worker.  I also decided to test this without using any background process just for comparison sake.  I used 1320 Text files of random length.  Test results:

Mac

Worker: 13.41 seconds

Thread:  35.53 seconds

No Thread:  34.85 seconds

Windows

Worker: 19.09 seconds

Thread:  20.04 seconds

No Thread:  25.79 seconds

I think this example is a bit better since there is a ton of string processing that obviously takes a while.  On macOS you can see that the Worker is clearly better than the Thread and even the no thread.  In Windows there is not much difference and I’m not sure how to explain this difference other than that maybe starting new processes in Windows is slow but still it’s obvious that Workers are better than no thread and slightly better than using the Thread.  With something that requires even more work I would expect this to be more pronounced.

One of the beefs I have with Workers is that you literally cannot test them in the debug environment.  When you test in the debugger you’re really working in a thread.  One of the strengths of Xojo is that working in the debugger is mostly the same as working in the real thing and Workers break that paradigm.  It’s a shame but maybe Xojo can fix this in a future release.

My other take away from using Workers is that it’s not a panacea for everything just like using Threads is not perfect.  Workers are Xojo console applications and there is overhead to starting them.  Xojo does make them easy to use by handling the inter application communications but with only string processing available you might be better off using IPCSocket communication but that’s not without its tradeoffs too.

Using Workers will take some work on your part to make sure you’re doing it as efficiently as possible.  Is it better to process a number of things in the Worker or do them one at a time?  And of course if you decide on Workers you’ll have more ‘joy’ in testing them.  Overall, ‘it depends’ on your needs to know if Workers are useful for your application.

Xojo 2020 Release 2.1

Xojo released a dot release this week that contains some important bug fixes.  Arm64 and iOS targets as well as the new Worker class received a number of important fixes.  Let’s get into some of the details.

The new Worker class will now use the Error event if the main app tries to start a worker without the required Helpers folder instead of throwing a Nil Object Exception.  The Error event no longer fires when the Worker quits normally.

ARM builds for macOS has added complexity for Build Steps.  We now can specify architecture for CopoyFilesSteps.  Resizing an array of structures no longer crashes on macOS ARM builds.

The ODBC database plugin no longer fails to connect.

ParseJSON no longer raises a failed assertion when passed an empty string.

The new DateTimePicker uses the standard border width and the control height was changed for Windows.  The DateSelected returns a valid DateTime object in Windows.  On the Mac side the control now honors the Top value when displayed in Text mode and you can now set the SelectedDate property regardless of the Regional settings of the user.

TabPanel.RemovePanelAt no longer throws an Out of Bounds Exception if the tab exists.

iOS has a number of changes.  Global.Speak is now System.Speak, Graphics.Font returns a Font object instead of iOSFont.  UDPSocket usage no longer causes the app to terminate after unlocking the phone.  The Runtime module methods are now accessible.  Graphics FontSize, Bold, Italic are removed in favor of the equivalent Font class properties.  

All users should update to Release 2.1 because of these important bug fixes.

The Advantages of a Job versus Consulting

For the past 20 years readers have heard me talk about consulting and the joys and challenges therein.  Those blog posts aren’t wrong but for the past nine months I’ve had a full time job and my perspective has changed.  Here are some things I’ve learned.

I’ve told friends that I have a ‘real job’ now.  In reality, it’s way easier than consulting.  While I was consulting I was always worried about where the next consulting project was going to come from.  I didn’t realize how much pressure and anxiety that introduced.  As my youngest child (now a junior in college) will tell you we talked about work (i.e. consulting) ALL the time because it was an all-consuming thing.  We either talked about the current jobs, the jobs we were bidding on, or whatever hassles we were dealing with in regards to employees, insurance, cash-flow, etc.

With a full time job I don’t have to worry about the next gig.  Now I just worry about the next project my bosses give me.  Well, it’s not worry, really, since we have an awesome team of developers but it’s more intrigue and wondering how deep of a rabbit hole I’m going to go down since we deal with some pretty arcane stuff.  Not worrying about the future is a huge relief (as much as anyone can feel safe during a global pandemic).

Along with the full time job I have all the benefits that is tough with your own business.  A steady income is an incredibly good thing since as a consultant you’re either rolling in dough (figuratively) or have none.  Having a 401k is a big relief as I go into the later part of my career.  Paid time off is another huge benefit since as a consultant you don’t make any money if you’re not working.  I don’t have to worry about health insurance now either and as a small business you get totally screwed over when it comes to health insurance in the United States.  As a business it was our number one expense after payroll and it was a nightmare to deal with since practically every year there was a 20% (or more) increase in premiums unless you switch plans which is a huge pain in the ass since you worry about is the new plan the same or worse than the old one and how will it affect you and your employees.

I’ve always been thankful that Carol was wiling and able to do the HR, payroll, accounting, and contract side of the business as well as being an awesome project manager and data goddess (DBA) on top of all that.  Without that help there’s no way I would have lasted 20 years.  Me as a developer will always tell the client that ‘sure we can do that’ but it’s helpful to have the project manager say, ‘yeah, and this is how much extra it will cost.’  Someone has to be the bad guy with the client and it’s nice when it’s not you.

Consulting is very much a ‘drinking from the firehose’ type business.  You either have too much work or not enough.  There is no such thing as the perfect amount of business.  As a solo developer there’s only so many hours you can work so then you start thinking of having employees.  We were extremely lucky to have found the employees we had since most lasted five or more years and were exceptionally productive.  But dealing with employees is hard when it comes to hiring and firing (we had a handful that didn’t last 90 days for one reason or another).  They all had their strengths and weaknesses and some you can put in front of a client and others are less than ideal. Some are great at debugging and others are not. Some are great a developing new code and others are not.

I always felt that our employees were an asset to us.  I always tried to hire people that were smarter than I am (some would say this is a very low bar, I know) and some competitors were aghast that I would ‘train my future competitors’.  Having a good consulting employee is not the same as creating a future competitor.  If they were going to have their own business they’d have had one already.  I guess that’s always been one of my beefs is that people think that having a business is the same as having a job and they are far from the same (see all the arguments above).

Do I have as much time flexibility in my job as I did consulting?  It’s really hard to say during a pandemic since all of the robotics programs I’ve been a part of are on (hopefully) temporary hiatus, the music festivals we usually go to were cancelled, and we aren’t meeting in-person with the groups we usually do, and travel was restricted for most of 2020.  The company I’m with has people scattered across four timezones so there is a lot of flexibility in when people start and end work and we’re all remote anyway.  As long as the work gets done no one minds much when you start and stop or if you work weekends (I have quite a few coworkers that are being their kids teacher at this point and keeping them going via Zoom with their school teachers – honestly I have no idea how they do it).  But honestly, as a consultant I worked most weekends and did a fair amount of work at night too so I think I’m working a more reasonable and balanced workload now than when I was a consultant.

Consulting was fun and rewarding.  It has perks that are amazing if you have a good accountant and follow the rules and have multiple people that can help split the work load and responsibilities and you’re willing to put in the work (like writing blogs and developing products!).  The pain of consulting is oftentimes not worth the hassle.  Before you leave your full time job for consulting think long and hard about doing it and maybe think about all the negatives.  Maybe give me a shout to try and talk you out of it.