Skip to content
This repository has been archived by the owner on Mar 16, 2021. It is now read-only.

Performance #113

Closed
xDragonZ opened this issue Jul 9, 2017 · 3 comments
Closed

Performance #113

xDragonZ opened this issue Jul 9, 2017 · 3 comments

Comments

@xDragonZ
Copy link

xDragonZ commented Jul 9, 2017

Hi,

I stumble upon another library called DPreference and did a quick test (using latest Tray version). Looks like Tray performance is not that good compare to DPreference, maybe due to DPreference is a simple library. Anyway hopefully will see some improvement for Tray in future.

OnePlus1
DPreference called setString 1000 times cost : 403
DPreference called getString 1000 times cost : 543

Tray called setString 1000 times cost : 8737
Tray called getString 1000 times cost : 3023
Samsung S8
DPreference called setString 1000 times cost : 231
DPreference called getString 1000 times cost : 154

Tray called setString 1000 times cost : 12946
Tray called getString 1000 times cost : 7965
@jannisveerkamp
Copy link
Contributor

jannisveerkamp commented Jul 10, 2017

The library doesn't persist its Preferences in a Database but within the SharedPreferences wrapped in a Content Provider. This should give a significant performance boost. I'm not entirely sure this really works across multiple processes though 💭

Regarding the speed issue: This could be solved using a Memory Cache (see the open Issue here.

@xDragonZ
Copy link
Author

xDragonZ commented Sep 17, 2017

Getting some high amount of ANR in play console report, not sure is related to Tray or not.

Any plan to provide an option to wrap the sharedprefrence in content provider? Meanwhile i will try dpreference library in production and let you know the result does it works well in multiprocess.

Edit:

  1. Oh never mind, just notice you mention that "metadata seemed to be more valuable to us" in readme
  2. Tested another library similar to dpreference and it works well (not tested on production yet)

@connectiblutz
Copy link

@xDragonZ What library did you test? Have you tested in production yet?

I am also seeing ANRs with traces going deep in to tray (as well as a few other places). They seem to be mostly on put calls
native: pc 000000000005f1fc /system/lib64/libc.so (__ioctl+4) native: pc 00000000000692c0 /system/lib64/libc.so (ioctl+100) native: pc 00000000000275f0 /system/lib64/libbinder.so (_ZN7android14IPCThreadState14talkWithDriverEb+164) native: pc 0000000000028044 /system/lib64/libbinder.so (_ZN7android14IPCThreadState15waitForResponseEPNS_6ParcelEPi+112) native: pc 00000000000282b8 /system/lib64/libbinder.so (_ZN7android14IPCThreadState8transactEijRKNS_6ParcelEPS1_j+176) native: pc 000000000001ff38 /system/lib64/libbinder.so (_ZN7android8BpBinder8transactEjRKNS_6ParcelEPS1_j+64) native: pc 00000000000dc2a0 /system/lib64/libandroid_runtime.so (???) native: pc 00000000012acb80 /data/dalvik-cache/arm64/system@framework@boot.oat (Java_android_os_BinderProxy_transactNative__ILandroid_os_Parcel_2Landroid_os_Parcel_2I+212) at android.os.BinderProxy.transactNative (Native method) at android.os.BinderProxy.transact (Binder.java:496) at android.content.ContentProviderProxy.insert (ContentProviderNative.java:474) at android.content.ContentResolver.insert (ContentResolver.java:1207) at net.grandcentrix.tray.provider.e.a (SourceFile:151) at net.grandcentrix.tray.provider.a.a (SourceFile:260) at net.grandcentrix.tray.provider.a.a (SourceFile:231) at net.grandcentrix.tray.core.c.a (SourceFile:310) at net.grandcentrix.tray.core.c.b (SourceFile:144)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

3 participants