Slowly Getting Faster
Byline went from 1.0 to 2.0 in little over three months, gaining along the way a totally redesigned interface, support for folders, a built-in web browser, and a host of other features. Byline 2.5, on the other hand, offers very few new features, yet when it is released in mid-April it will have been a whole six months since 2.0. Why?
Part of the answer is boring; other programming projects, moving house and general sloth all contributed to a much longer development time than I expected. But the other part of the answer is much more interesting — or at least slightly less boring, I hope.
What was wrong with Byline 1.0?
Byline 1.0 was the result of only three months of frenzied development. It had a number of shortcomings; one of the main ones was that it would only sync twenty-five items from each list at a time. When syncing each list it would initiate a download of data for the newest twenty-five items, wait for the download to finish, and then use the data to update the list. This was easy to code, as all the Atom parsing and updating of the data model and user interface could be done in a single step.
So what was wrong with Byline 1.0?
Nothing! This method of syncing worked well, because Byline only ever had to process twenty-five new items at a time. There wasn’t a problem until Byline 1.0.2, which offered an option to sync up to two hundred items at a time from each list. Suddenly, the processing time required to parse the data for a whole list in one big chunk was long enough to make the user interface freeze noticeably. The processor would sit idle until the data had downloaded in full, and then kick into overdrive, delaying the whole syncing process and leaving the interface unresponsive for several seconds.
Should I have done things differently from the beginning?
Not really. Less code is better code, and the best code is no code. Most of the time. In rare cases fast code is better than less code, but it’s usually impossible to work that out before you’ve written the concise version and tested it to death with performance tools.
What have I done to solve the problem?
I’ve implemented progressive syncing. In other words, as soon as Byline begins to receive data for the list it’s syncing, it starts parsing the data and updating the list. New items are added gradually starting from the top of the list, and a heuristic is applied to determine which items should be removed from the list as the sync proceeds, so that you don’t see a jumbled mess if you view the list while it’s syncing. Because the data is parsed a little at a time the user interface never becomes unresponsive, and you can start browsing new items straight away, as soon as they appear.
The only downside is that there is a performance penalty incurred by parsing the data in small chunks and updating the user interface gradually throughout the syncing process. This results in marginally slower syncing over a very fast Wi-Fi connection, when the data would typically load very quickly anyway and processor speed is the major bottleneck. Over a 3G or Edge connection syncing is now faster, as the processor gets put to work straight away rather than waiting around for significant periods of time while the data it needs is downloaded in full.
In any case, it all feels faster now that the user interface is responsive.
What else is new in Byline 2.5?
Most other improvements are also related to performance. Byline is now much more reliable when handling large numbers of folders, and should be less prone to forgetting data between runs, a problem which was caused by the length of time it took to write the data model to permanent storage.
One major new feature is a button to toggle a “sort by feed” mode — this should make quite a few people happy! Other than that, you’ll have to wait and see … but not for very much longer.
