I just tried it on my iPad with internet download for whole Europe. It only took a few seconds. So at least for actual hardware this seems a non issue to me.
I have never found the app to be particularly resource hungry on several varieties of iPad. There is a short delay after download. And I tend to be running GP or FF at the same time.
Sebastian_G wrote:
A much more CPU friendly compression could be used but that would mean bigger files. On a high speed Internet connection it would not matter so much but the ADL system is all about data volume.
Do you use the same compression if the ADL Connect application is using an internet connection?
I have run ADLconnect on two different iPads, now iPad Air 2 and iPhone 6. Never observed performance issues. It takes a while to download the weather (over satellite) and then another few seconds before it is displayed, but we are not dealing with real-time data. I do not have a CPU monitor on my iPad, but with iOS 11 I can run two applications simultaneously without any issues.
Following some tests, the answer to this is, as so often, “it depends”.
It depends on the route you have loaded and what exactly your screen is showing. Some timings:
T705 4.4.2
initial EGKA-LDSB data download 9 secs, data rendering 8 secs
subsequent EGKA-LDSB download 4 secs, data rendering 8 secs
initial EGKA-LFAT data download 4 secs, data rendering 5 secs
subsequent EGKA-LFAT download 4 secs, data rendering 8 secs
S7 6.0.1 (extremely slow interface – several secs delay after any button press)
initial EGKA-LDSB data download 3 secs, data rendering 15 secs
subsequent EGKA-LDSB download 4 secs, data rendering 8 secs
initial EGKA-LFAT data download 4 secs, data rendering 5 secs (15 secs on another occassion)
subsequent EGKA-LFAT download 4 secs, data rendering 8 secs (15 secs on another occassion)
The “initial” figures obviously don’t matter. Also the initial download time can be concealing stull like ADL server login which is to be expected to be variable.
Obviously it is strange that the initial rendering of EGKA-LFAT took 5 secs but 8 secs subsequently.
But obviously shorter routes are a lot quicker to render, as will be smaller flight plan segments.
For example on EGKA-LDSB (a long flight) if I display the section EGKA-LFSO it renders in 4 secs but the whole route takes 8 secs. So the screen zoom makes a 2:1 difference.
I also noticed something else. If your screen is showing the whole route, the rendering is about 2x faster than if it is showing just a small part of the route. For example EGKA-LDSB shown whole renders in (as above) 8 secs but if I zoom in to show basically just the Alps it renders in 15 secs (the download takes the same time). This is presumably due to the higher resolution of the displayed data in the latter case. As one might expect…
The above is on ADSL, 30mbps DOWN. In fact I was running the two devices side by side.
I thought the S7 had a faster CPU because it arrived about 2 years after the T705 but actually possibly not really, depending on how many cores the app can make use of. The T705 is “Exynos Octa-core processor (1.9GHz & 1.3GHz)”. The S7 is “Exynos 8890 quad-core 2.3 et quad-core 1.6 GHz”. The T705 has 8 cores and the app is altogether much more responsive on it, showing none of the user interface delays which I see on the S7. But that’s fine; the phone app would be a backup for a backup… But an interesting data point is that the rendering speeds are the same so perhaps the app is not using all available cores. Well, all apps have the same issue; they have to be specially written to run multiple threads and not all algorithms lend themselves to multiple threads. But maybe this is a useful pointer to speeding up both versions of the app: use more cores if available. I am sure a modern high-end Ipad is faster than the stuff I have.
I suspect there is an issue on the S7 (perhaps more specifically android v6) which slows down the UI button response so much.
As I wrote earlier, if I was the programmer, I would fix all this simply by downloading and rendering in the background, and then flip it over when it’s all ready. It’s a very old technique which I used c. 1980 to display some quite slick moving graphics on a 4MHz Z80 based board which used an NEC 7220 graphics processor 
and it works just as well today – especially in an application where the data changes so infrequently but the pilot needs to see the screen more or less continuously. The rendering etc times above are a non issue in actual use but doing it in the background would make the app nicer to use.
These comments are intended to be constructive, as always.
One thing to check is how much space is free on the device. iOS devices slow down significantly if there is very little space left on it.
That is true on Android as well. The fuller persistent storage is, the more fragmented, the more time it takes to read or write data.One thing to check is how much space is free on the device. iOS devices slow down significantly if there is very little space left on it.
My T705 has little flash left – 2.85GB free (16GB total size). The S7 has 9.98GB free (32GB total size). As for RAM, I am not sure where to look, but I had no other apps in the background during the test.
Both devices are rooted, with 128GB SD cards, but neither device uses that for the ADL app. I use the SD cards for data, mainly.
Not to start a thread drift, but how does fragmentation affect the performance of a solid state disk device? I’m not talking about the fragmentation introduced by firmware for purposes of wear leveling, nor do I expect there to be a CoW snapshot cleanup in the picture here. I’m pretty sure even Peter’s tablet doesn’t have a mechanical HDD… ;)
