Re: [tryton-dev] Record.expr_eval

2014-05-09 Thread Cédric Krier
On 08 May 11:36, Cédric Krier wrote:
 I made a POC for issue1318: http://codereview.tryton.org/12291003/
 As far as I see it gives a good improvement and doesn't seem to affect
 the behavior. It is based on the idea that the content of the cell
 should be recomputed only when a display is called.

The POC is not a patch ready for review.
I really see a good improvement on my slow machine.

-- 
Cédric Krier - B2CK SPRL
Email/Jabber: cedric.kr...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/


pgpj8MmKHMr6E.pgp
Description: PGP signature


Re: [tryton-dev] Record.expr_eval

2014-05-09 Thread Sergi Almacellas Abellana

El 09/05/14 20:10, Cédric Krier ha escrit:

On 08 May 11:36, Cédric Krier wrote:

I made a POC for issue1318:http://codereview.tryton.org/12291003/
As far as I see it gives a good improvement and doesn't seem to affect
the behavior. It is based on the idea that the content of the cell
should be recomputed only when a display is called.

The POC is not a patch ready for review.

I'm wondering why you're saying its not ready for review?

I really see a good improvement on my slow machine.
I just tested two clients on the same database, on patched and another 
not patches, and I also see a good improvement in my machine, especially 
when opening closing on the 4th level and above. My impresion is that 
with the patch the records are opened/closed at the moment, but without 
the patch it spends 1sec (more or less) to open/close a record.


I also noticed that the client without the patch gets 100% of the CPU, 
and the patched version only uses 20%


So for me it's a very good improvement.


--
Sergi Almacellas Abellana
www.koolpi.com
Twitter: @pokoli_srk



Re: [tryton-dev] Record.expr_eval

2014-05-09 Thread Cédric Krier
On 09 May 23:42, Sergi Almacellas Abellana wrote:
 El 09/05/14 20:10, Cédric Krier ha escrit:
 On 08 May 11:36, Cédric Krier wrote:
 I made a POC for issue1318:http://codereview.tryton.org/12291003/
 As far as I see it gives a good improvement and doesn't seem to affect
 the behavior. It is based on the idea that the content of the cell
 should be recomputed only when a display is called.
 The POC is not a patch ready for review.
 I'm wondering why you're saying its not ready for review?

s/not/now/

-- 
Cédric Krier - B2CK SPRL
Email/Jabber: cedric.kr...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/


pgpMAGS2IGz54.pgp
Description: PGP signature


Re: [tryton-dev] Record.expr_eval

2014-05-08 Thread Cédric Krier
On 07 May 12:03, Cédric Krier wrote:
 On 07 May 02:24, hendrik.brande...@googlemail.com wrote:
  Hello,
  
  I have been successfully implemented a tryton 3.2 installation and have a 
  problem regarding the Record.expr_eval method of the client: If I use the 
  client out of the box without modifications, displaying our chart of 
  accounts takes a long time if we drill-down to level 4 or deeper. Used 
  chart of accounts is the german SKR03. 
  
  After reading the source and perform some debugging sessions, I found out, 
  that the following part of the Record.expr_eval ( 
  http://hg.tryton.org/tryton/file/88501503f5b9/tryton/gui/window/view_form/model/record.py#l502
   
  ) is responsible for the performance issue:
  
  ctx['context'].update(self.context_get())
  ctx.update(self.get_eval())
  
  If I comment this lines out, the client reacts as desired. But: only for 
  the chart of accounts and for most of the list-views. All forms remains 
  read-only and are not usable.
  
  Is it possible, to give me a hint, how to resolve this issue? I try to get 
  the current view-state or make a flag, but both of them do not work as I 
  expected this. 
 
 I think we can not really improve those 2 lines because they are needed
 to get a correct context.
 But one thing, I already stated, is that the setter method of the
 columns [1] is called very often and this setter need to get the states
 of the field to make a proper rendering which leads to calling
 Record.expr_eval.
 Maybe [2] is a possible solution or we should cache the states on the
 cell but then the problem is invalidation of this cache (as usual).
 
 [1]
 http://www.pygtk.org/pygtk2reference/class-gtktreeviewcolumn.html#method-gtktreeviewcolumn--set-cell-data-func
 [2] https://bugs.tryton.org/issue1318

I made a POC for issue1318: http://codereview.tryton.org/12291003/
As far as I see it gives a good improvement and doesn't seem to affect
the behavior. It is based on the idea that the content of the cell
should be recomputed only when a display is called.


-- 
Cédric Krier - B2CK SPRL
Email/Jabber: cedric.kr...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/


pgpb3FfAodJnm.pgp
Description: PGP signature


[tryton-dev] Record.expr_eval

2014-05-07 Thread hendrik . brandes . 7
Hello,

I have been successfully implemented a tryton 3.2 installation and have a 
problem regarding the Record.expr_eval method of the client: If I use the 
client out of the box without modifications, displaying our chart of 
accounts takes a long time if we drill-down to level 4 or deeper. Used 
chart of accounts is the german SKR03. 

After reading the source and perform some debugging sessions, I found out, 
that the following part of the Record.expr_eval ( 
http://hg.tryton.org/tryton/file/88501503f5b9/tryton/gui/window/view_form/model/record.py#l502
 
) is responsible for the performance issue:

ctx['context'].update(self.context_get())
ctx.update(self.get_eval())

If I comment this lines out, the client reacts as desired. But: only for 
the chart of accounts and for most of the list-views. All forms remains 
read-only and are not usable.

Is it possible, to give me a hint, how to resolve this issue? I try to get 
the current view-state or make a flag, but both of them do not work as I 
expected this. 

Thank you and kind regards,
Hendrik 


Re: [tryton-dev] Record.expr_eval

2014-05-07 Thread Cédric Krier
On 07 May 02:24, hendrik.brande...@googlemail.com wrote:
 Hello,
 
 I have been successfully implemented a tryton 3.2 installation and have a 
 problem regarding the Record.expr_eval method of the client: If I use the 
 client out of the box without modifications, displaying our chart of 
 accounts takes a long time if we drill-down to level 4 or deeper. Used 
 chart of accounts is the german SKR03. 
 
 After reading the source and perform some debugging sessions, I found out, 
 that the following part of the Record.expr_eval ( 
 http://hg.tryton.org/tryton/file/88501503f5b9/tryton/gui/window/view_form/model/record.py#l502
  
 ) is responsible for the performance issue:
 
 ctx['context'].update(self.context_get())
 ctx.update(self.get_eval())
 
 If I comment this lines out, the client reacts as desired. But: only for 
 the chart of accounts and for most of the list-views. All forms remains 
 read-only and are not usable.
 
 Is it possible, to give me a hint, how to resolve this issue? I try to get 
 the current view-state or make a flag, but both of them do not work as I 
 expected this. 

I think we can not really improve those 2 lines because they are needed
to get a correct context.
But one thing, I already stated, is that the setter method of the
columns [1] is called very often and this setter need to get the states
of the field to make a proper rendering which leads to calling
Record.expr_eval.
Maybe [2] is a possible solution or we should cache the states on the
cell but then the problem is invalidation of this cache (as usual).

[1]
http://www.pygtk.org/pygtk2reference/class-gtktreeviewcolumn.html#method-gtktreeviewcolumn--set-cell-data-func
[2] https://bugs.tryton.org/issue1318

-- 
Cédric Krier - B2CK SPRL
Email/Jabber: cedric.kr...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/


pgpYRf_EO7LYu.pgp
Description: PGP signature