On mer, 2014-07-02 at 16:43 +0900, Carsten Haitzler wrote: (snip)
> ok sorry - bad illustration. MESSAGE api does allow this > > https://review.tizen.org/gerrit/gitweb?p=framework/api/messages.git;a=blob;f=include/messages.h;h=09e7a96e97d4ae7973ac8b8c2a80a9be3e45c279;hb=HEAD > > you get message count, then using messages_foreach_message() or > messages_search_message(), then per messge you messages_get_time(), > messages_get_text(), messages_get_address(), messages_get_message_type() > etc. etc. > > now let's imagine you are scrolling through a list of 1000's of > messages. yoou have a big screen that can display a list of 100 > messages. as you scroll, you will have to (if scrolling fast) query 100 > new messages per frame (you scroll 1 screne or more worth of content > each frame). at 60hz. and you need to spend your time also rendering and > doing other things. sure - do the queries in a thread... but hear me > out. let's assume you have a dedicated thread for this ALONE. that means > 6000 messages need querying for display every second (100*60). if each > of the above calls (first to list the 100 messages, then per message get > address, type, text etc.) are wrapped in SAPI as client/server > round-trips... you are doing at least 4 round trip calls per message... > 0.4 ms at a best case... 6000 times per second to keep up display. that > means we are burining 2400ms of round-trip query time PER 1000ms of time > we have. we just can't keep up. this is a best scase scenario. it gets > worse on different cpu architectures etc. > > if SAPI is just a wrapper around CAPI call-by-call, this is doomed to > have these kinds of performance issues all through it. and that above is > the best case scenario. it has to be far more involved and intelligent > than that. > > example above - when you query for a bunch of messages ALL of the > messages and data are transferred locally to the client side in memory > and after that all data is local, so the gets then are simply getting > ptrs inside an already client-side structure. Hi Carsten, You are right and I let you image what it could be if DBUS (or even KDBUS) was used instead... ;) But, currently, I have no time to bench it <o_O> The current compromise is to advance and have security inside Tizen 3. As you perhaps remember, the security should no more be checked in the user space, it have to be a service. That's the problem. The problem of time that you described really exist and have to be treated. I agree with that. As wrote Dominique, for this kind of problem can be solved by separating the signaling of the content. The precise answers for each API have to be studied. That's a lot of work. A lot of compromises too. The example of the emails is really good because emails are not seen as being time critical data but it can be a timing problem because the count of emails can be high. Best regards José _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
