able takes 14 secs to put services/characteristics in dictionary

[robgar2001]

Hi,

The conversion from Java List to Python dictionary takes 14 seconds or longer. We only have one service with one characteristic running at the server side.

Our first thought are due to Pyjnius interaction while iterating. Although this seems very odd. What could cause this?

The specific method mentioned: https://github.com/b3b/able/blob/b45539d6e6150eea0bcbc0a4868623f7d74b86ce/able/android/jni.py#L54-L67

We wrote a 'fix' by doing the iteration in Java, this fixed the issue. If nobody can present a reason why Python might take so long, I would be willing to create a pull request for the Java implementation.

Kind regards,

Robbe Gaeremynck

[b3b]

Hi, Robbe.

I don't see, why it can take so long. There is no interaction with device in the on_services method, only conversions.

I tried profiling on_services with the app: https://gist.github.com/b3b/41970e0f9505afcddad8a4e17daf7d1a For different devices (with single and multiple services/characteristics), total time is not exceed 0.4 seconds:

0-31 22:53:07.025 13353 16813 D BLE-python: Connected to GATT server, status:0
10-31 22:53:07.031 13353 16813 I python  : [DEBUG  ] [on_connection_state_change status=0 state] 2
10-31 22:53:08.655 13353 16813 D BLE-python: onServicesDiscovered - success
10-31 22:53:08.760 13353 16813 I python  : [DEBUG  ] [on_services ] called
10-31 22:53:08.799 13353 16813 I python  : [DEBUG  ] [on_services after services.toArray()] 0.038773
10-31 22:53:08.826 13353 16813 I python  : [DEBUG  ] [Service discovered] 16fe0d00-c111-11e3-b8c8-0002a5d5c51b
10-31 22:53:08.888 13353 16813 I python  : [DEBUG  ] [Characteristic discovered] 16fe0d01-c111-11e3-b8c8-0002a5d5c51b
...
10-31 22:53:08.968 13353 16813 I python  : [DEBUG  ] [on_services after service.getCharacteristics().toArray()] 0.208832
10-31 22:53:08.969 13353 16813 I python  : [DEBUG  ] [on_services total time] 0.209554

Maybe there were some conditions, that could affect the situation? Does it happen with any or only with a specific device?

Of course, it will be interesting to see a Java implementation, but it will be great to reproduce the issue and find out the reason.

[robgar2001]

Hi, @b3b .

Here is an update of the debugging progress so far:

• Problem is not device specific, happens on both a snapdragon 665 and a snapdragon 8xx phone.
• Our app is single threaded but async. I tried to build your debug app with kivy running async, worked just fine.
• We tried building a Java map and passing the map to Python. Still same problem. So it's really calling the Python method that takes so long.
• Also note, gui is still running fine and smooth, so I assume performance isn't the problem.

Planned debugging actions:

• Passing a non bluetooth related map to Python. Just a big data object.

Looking forward to your thoughts and opinion

Kind regards,

Robbe

[b3b]

Hi, @robgar2001 .

So there are no delays when using debug app? Maybe it be possible to prepare a minimal example that reproduces the delay? And, maybe delay is happen on the BLE.on_services event handler, and not in the PythonBluetooth.on_services itself?

I tried async loop version of the debug app: https://gist.github.com/b3b/c7b5f92c655bfa31ff34bf4efeef636c And also did not find any delays.

[robgar2001]

Hi, @b3b

Finally, issue is solved. Sadly enough, I can't give an exact explanation why the fix caused the issue.

While debugging we searched for other places where Java/Android calls where being made. We also use the kivy.core.camera class to capture our android camera preview. This is done in a asynchronous while loop. I forgot to do 'await asyncio.sleep()' at the end of the loop. This shouldn't matter, cause we do await [def] calls in the method itself.

The strange thing is, gui was still working fine. So it was not like the asyncio loop was full occupied by doing that one task.

Only thing I can think of is that Python asyncio scheduler was so busy that it couldn't receive the Python to Java call or something like that.

[b3b]

Hi, @robgar2001

Glad you got the issue solved. Another source of issues is that BLE handlers could be called from background threads. It might be worth reconsidering how able works with threads, and make sure only main thread is used.