New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bad performance #41

Closed
Robbi-Blechdose opened this Issue Jun 18, 2018 · 12 comments

Comments

Projects
None yet
2 participants
@Robbi-Blechdose

Robbi-Blechdose commented Jun 18, 2018

I recently tested my app on a real device (Moto G5, XPeria E4g), and the performance was astonishingly bad.
Instead of the ~28 fps I was seeing in the emulator, I got ~0.4 fps.
Because of this, I ported the UI code to Java and used Chaquopy with the ftrobopy for the backend only, but the performance was still as bad (and fine on the emulator).
Is there any way to fix this?

@mhsmith

This comment has been minimized.

Member

mhsmith commented Jun 18, 2018

The emulator is often a bit faster than a real device, but I've never seen such a large difference as this. Can you be more specific about exactly what part is running slow? You could insert some print statements into your code and then look at the timestamps in the logcat.

@Robbi-Blechdose

This comment has been minimized.

Robbi-Blechdose commented Jun 18, 2018

I'll see what I can do, but could the problem be that networking via python is just simply too slow?

@Robbi-Blechdose

This comment has been minimized.

Robbi-Blechdose commented Jun 18, 2018

This is the Java Version using the ftrobopy via Chaquopy:

long timeA = System.currentTimeMillis();
int[] buffer = ftrobopy.callAttr("getCameraFrame").toJava(int[].class);
System.out.println("Cam update took " + (System.currentTimeMillis() - timeA) + "ms.");

I'm seeing values between 500 and 800ms here, definetely too much.
Meanwhile the emulator reports around 90ms, making for a smooth framerate.

@mhsmith

This comment has been minimized.

Member

mhsmith commented Jun 18, 2018

I doubt that networking in itself would be that much slower in Python than Java, though the actual network connection might be slower on your phone than on your computer. I assume the images you're transmitting are the same resolution in both cases?

If it's not networking-related, then the data conversion might be the issue. Can you get some separate timings for callAttr and toJava?

@Robbi-Blechdose

This comment has been minimized.

Robbi-Blechdose commented Jun 18, 2018

I doubt the network is the bottleneck, as the controller the phone or my PC with the emulator are connecting to is using WiFi, so the phone using WiFi instead of cable should not make a difference.

Emulator:
callAttr: ~12ms
toJava: ~98ms

Phone:
callAttr: ~12ms
toJava: ~600ms

@mhsmith

This comment has been minimized.

Member

mhsmith commented Jun 18, 2018

Yeah, you're going to need a more efficient way of passing the data to Java. I'll implement the bytes optmization I mentioned in #40 (comment), and release that in the next few days.

Just for context, what is the approximate size of this array?

@Robbi-Blechdose

This comment has been minimized.

Robbi-Blechdose commented Jun 18, 2018

The size is apparently dependent on the image, since it's compressed (I think JPEG). Anyway, buffer.length reports ~14000 bytes size.
So what would be the more efficient way to get that data to Java?

@mhsmith

This comment has been minimized.

Member

mhsmith commented Jun 18, 2018

I'm afraid I've got no other suggestions at the moment, you'll have to wait for the next release. We'll have it ready in the next few days. Sorry for the inconvenience.

@Robbi-Blechdose

This comment has been minimized.

Robbi-Blechdose commented Jun 18, 2018

So the next release will fix this problem?
That'd be awesome.

BTW, it's awesome that you're responding so quickly and try to help, not all devs are like that :)

@mhsmith

This comment has been minimized.

Member

mhsmith commented Jun 20, 2018

Chaquopy 3.3.0 is now available, please give it a try. As well as improving performance for bytes to byte[] conversions, it also automatically handles the signed/unsigned conversion.

So you should now be able to do something like:

frame = fttxt.getCameraFrame()
if frame is not None:
    bitmap = BitmapFactory.decodeByteArray(bytes(frame), 0, len(frame))

Or in Java:

PyObject frame = ftrobopy.callAttr("getCameraFrame");
if (frame != null) {
    byte[] frameData = py.getBuiltins().callAttr("bytes", frame).toJava(byte[].class);
    Bitmap bitmap = BitmapFactory.decodeByteArray(frameData, 0, frameData.length);
}
@Robbi-Blechdose

This comment has been minimized.

Robbi-Blechdose commented Jun 20, 2018

Okay, so, WOW!
This update was quick, and it was GOOD.
I'm now seeing times below 10ms, often ~6ms, on my real device, the performance is better than it was before on the emulator! Really nice work, I think you can close this issue. :)

@mhsmith

This comment has been minimized.

Member

mhsmith commented Jun 20, 2018

That's great to hear, thanks.

@mhsmith mhsmith closed this Jun 20, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment