On 07/02/2014 08:24 PM, José Bollo wrote: > 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>
indeed dbus would be worse... :) i was more saying "how much worse is this vs no ipc at all - ie as it is now". :) > 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. sure. i agree we should have good security - more fine grained control is better. but it shouldn't come at a significant expense in performance. this simply reduces battery life, hurts usr expeirence and ultimately all the best security on the planet is pointless if users just abandon the plantform because they are unhappy with their performance. making a perfectly secure os that no one wants is a pretty pointless task. there has to be a middle ground. :) as such wraping every CAPI calll in an ipc call is not going to fly - it's going to create nasty bottlenecks in a range of usages. this has to be done intelligently and maybe it requires we go slowly and wrap 1 api at a time, carefully redesigning the client-side lib to have minimal round-trips and lots of client-side data shadowing. it may take longer than expected. i just think we likeely nheed to account for this in timelines and goals. > 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é > > > -- The above message is intended solely for the named addressee and may contain trade secret, industrial technology or privileged and confidential information otherwise protected under applicable law including the Unfair Competition Prevention and Trade Secret Protection Act. Any unauthorized dissemination, distribution, copying or use of the information contained in this communication is strictly prohibited. If you have received this communication in error, please notify the sender by email and delete this communication immediately.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
