openerp-expert-framework team mailing list archive

["Borja López Soilán (Pexego)" <borjals@xxxxxxxxx>]

Hi guys, I simply think that both optimizations (search_read + 
search_browse) should go into 6.0.

My thoughts:

   * We haven't still released RC1, so the feature-list shouldn't be
     hard-freeze yet.

   * They are "/one small step for a /developer, /one giant leap for
     the /community".
     Those two small improvements to the ORM may be used to greatly
     improve the performance on custom modules yet to be developed.
     OpenObject as a framework would benefit a lot from this!

   * Both changes are so small and independent that they hardly affect
     anything.

   * We don't need to apply this optimization on the current addons
     yet, just the framework. We may just use them on the new code
     (future extra-addons, localization modules) that won't be freeze
     yet. So it is not risky at all.

   * The GTK client could easily make use of these methods to optimize
     its performance on high latency networks.
     This wouldn't require to touch any "business code", so it should
     be pretty straightforward (one day, couple of days?), I don't see
     why not to implement it just before RC1.


Raphaël Valyi wrote:
> Hello xrg,
>
> well, I don't understand why you won't package that search_read 
> OpenERP v6 (at least our naive version if you are unsure about your 
> implementation). It doesn't matter at all how search_read is 
> implemented in a first approach: in our test, even if search_read 
> simply calls search and then read, on the client side, even on 
> localhost or local network it's already nearly 2x faster, just because 
> it avoids to pass twice in the Python HTTP layers both in the client 
> and the server. Of course with latency (like Saas server), then it's 
> even closer to twice as fast. Aren't you folks at OpenERP S.A. not 
> interested in the Saas?
>
> Isn't version management all about API management? Isn't it all about 
> packaging a stable API in a release and then let modules use that API 
> during the release life?
>
> Then what is the reason you don't throw that method in, so that, 
> during the v6 life, modules and clients could eventually use that API, 
> especially to reach better speed.
> In what does it impact the version management? Where is the hard work 
> here?
>
> Again, yes, we will need ORM optimizations in the future. But what we 
> are talking about here is much simpler and has way more impact: if 
> your network has a 0.2 sec latency because your server is on an other 
> continent, then having such a method might often result the GTK client 
> have requests in something 1 sec instead of 1.2 sec, this will often 
> bring something like 20% faster for 3 lines of search_read code, what 
> is the big deal?
>
> Sorry, I simply don't understand that stance. Could you explain us?
>
>
> Raphaël Valyi
> Founder and ERP Consultant
> +55 21 3010 9965
> http://www.akretion.com <http://www.akretion.com/>
>
> <http://www.akretion.com.br/>
>
>
>
> 2010/9/17 P. Christeas <p_christ@xxxxxx <mailto:p_christ@xxxxxx>>
>
>     Hi,
>     I've been following your tweets about the search_read method.
>     You may have seen that I had implemented that back in June for the
>     browse()
>     method (but wanted to show that it was possible):
>     http://git.hellug.gr/?p=xrg/openobject-server;a=commit;h=a9fb6a76eb6db33fc
>
>     yes, not only me, but other people here have thought about some
>     optimizations
>     that we could put into the ORM. I'll be following your progress,
>     but please do
>     so yourself: it should worth trying my "trunk-pg84" branch and see
>     how it
>     performs.
>
>     I'd also like to ask you /not/ to expect API changes for v6.0 . We
>     are trying
>     hard here to "close" the version and make a release. Then, we
>     could evaluate
>     all the patches (mine are sitting in a queue, too) and put the
>     improvements in
>     for v6.+ .


--
Borja López Soilán
borjals@xxxxxxxxx

Pexego Sistemas Informáticos S.L.
Avenida de Magoi 66 - 27002 Lugo (España)
Tel./Fax 982801517
http://www.pexego.es 


AVISO LEGAL - CLÁUSULA DE PRIVACIDAD
Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si no es usted el destinatario indicado, queda informado de que la utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.