search

evrencoskun / TableView

TableView is a powerful Android library for displaying complex data structures and rendering tabular data composed of rows, columns and cells.
MIT License
3.14k stars 459 forks source link

Sorting optimization #196

Open vkhaitan opened 5 years ago

vkhaitan commented 5 years ago

I have got long list of more than 6000 rows. If I sort them, it takes long time upto the point of hanging up. After may be a minute, it sorts properly. I have turned animation off,despite that it is a problem.

Sorting list of 6000 number should be a breeze, in few milliseconds. So, the time goes in updating the UI. I see that you are using DiffUtil. It is good for updating, but is it really good for sorting purpose ?

If you take numbers and just update all the visible rows, it should be done in milliseconds. However, it takes about 1 minute.

vkhaitan commented 5 years ago

Let me also add that I am using Xamarin.Android . So I need to return Java.Lang.Object from C# float whenever content is asked.

vkhaitan commented 5 years ago

Okay, I finally found that the real culprit is JNI . JNI has huge problem if you allocate too many objects on Android side. I was hitting maximum, hence the slowdown. I wrote down "Cell" class on Java side, and sorting issue solved.

vkhaitan commented 5 years ago

I realized that Since GetContent() would be called frequently, there is no way to avoid high frequency JNI boundary crossing. So optimization need to stop this. So I ported your complete library with latest code to C#/Xamarin.Android. Now everything is in C# and it became fast. Anyway, C# is faster than Java :-) . Sorting etc. work fine. Filter I need to test, since I never used it.

Liar1995 commented 5 years ago

Hi，@vkhaitan ，I hope you can submit a JAVA version of pull requests to solve the problem of sorting UI latency in large data 👍

vkhaitan commented 5 years ago

Actually I didn't optimize the code. My problem was different, related to C# version, which called JNI. JNI is costly hence the slugginess. I believe that the way code is written for sorting, is not optimized one. The real problem is getContent() function call. If you have 100 items, it would be called 1500 times. That's logical, since sorting is O(nlog(n)) operation. However, the biggest issues is that sorter doesn't cache the number, instead it directly calls getContent(). So somehow getContent needs to be inlined, if you want good performance. Or, Cache the result of getContent() in library.

vkhaitan commented 5 years ago

I just did some investigation and found that without getContent() and return typechecking optimization, it can still be speeded up by almost 30 times! It is just evil code. Now, If getContent() caching and typechecking optimization is done, it would almost become instant (in the range of may few milliseconds) for 6000 rows. IT IS OMG! UI latency is zero because of recyclerview.

vkhaitan commented 5 years ago

Okay. Updated the C# version and sorting works almost instantly. at least 30 times faster now. code was calling indexOf() in a for loop. That is evil. I just removed it and did it in better way.