On 07/02/2014 04:08 PM, Patrick Ohly wrote: > On Wed, 2014-07-02 at 10:31 +0900, Carsten Haitzler wrote: >> On 07/02/2014 08:58 AM, Dominig ar Foll (Intel OTC) wrote: >> >>> Le 02/07/2014 01:01, Carsten Haitzler (The Rasterman) a écrit : >>> >>>> O >>>> >>>> 2. what's the call overhead without socket (cost of a function call)... :) >>>> that >>>> is what you are comparing against. >>>> >>>> the best case scenario here - 0.1ms ... give a BEST case of 10,000 calls >>>> per >>>> second.. assuming the ONLY thing i do is that and nothing else... that's >>>> pretty >>>> low. but then again you need some level of real-life data >>> Remember that we are only taking about the signaling API and not the >>> transfer API. >>> So having 10000 of call per second is not a realistic concern. >> i thought this was meant to be an ipc round trip per "api"? > Indeed. So let's look at the mail API: > > https://review.tizen.org/gerrit/gitweb?p=platform/core/api/email.git;a=blob;f=include/email.h;h=61676806748c7ed44ee4505e0c71588832ec82c4;hb=refs/heads/tizen > > There's email_create_message() giving us a local pointer. Then there's > email_set_subject(), taking such a pointer. This is a specific example > of the problem that I mentioned in my other email, where the proxy needs > to validate the pointer before calling the original CAPI > email_set_subject(). > > It's also an example for "local function call becomes > RPC" > (https://review.tizen.org/gerrit/gitweb?p=platform/core/api/email.git;a=blob;f=src/email.c;h=a6d447602a965ef25e610f13edc63a52c11bf4be;hb=refs/heads/tizen). > > One can argue that this function will only be called rarely. But is that > the case for all functions? > > And is this really the right API to look at in the first place? See > below. > >>> I invite you to look at the current CAPI which are the candidate for >>> wrapping, you will find an updated list here : >>> >>> https://wiki.tizen.org/wiki/User:Sdi2 > These are the services. Do you have the corresponding list of APIs which > are meant to be wrapped? > > For email, there's the capi referenced above (pretty limited, only > supports composing and sending an email) and the underlying > email-service API > (https://review.tizen.org/gerrit/gitweb?p=platform/core/messaging/email-service.git;a=tree;f=email-api/include;h=cbe9692e989ae1b5abbfa5bb065048f4bbc81306;hb=refs/heads/tizen). > > It was said that Crosswalk should rely on SAPI to implement the web > APIs. For email, the capi is not sufficient for implementing the Tizen > messaging API > (https://developer.tizen.org/dev-guide/2.2.1/org.tizen.web.device.apireference/tizen/messaging.html). > >> email and messaging, from memory allow you to fetch messages/emails. >> that means you have data to fetch... ? > The capi for email doesn't allow fetching, the email-service does. So we > need to clarify first which one is supposed to be wrapped.
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. -- 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
