* Betr.: " Re: [tryton-dev] EP2010 and Tryton Performance Improvements" (Thu, 22 Jul 2010 09:35:25 +0200):
> > Now, back to the issue at hand: > > > > Tryton code (IMHO) is mature enough for us to start thinking of performance > > improvements. As discussed with Cedrik, I request all of you to propose or > > update tickets with the file and line number(s) of code where you think > > there is a performance issue. This collection could later be discussed and > > optimised. > > > > @cedk, could you recommend if we should start thinking of patches/diff also, > > or just collect the points where we think the issues exist. > > I think we should focus first on patern that has issues. > And after when we decide the right way to fix, we fix it with patch all over > the place. AFAIS we have improvements in the client on displaying large number of records, but there are still issues (especially on large numbers of records in a o2m). I think e.g. https://bugs.tryton.org/roundup/issue1623 could be a real important improvement. So for me performance issues are already collected under issue type performance . > > Issue for Python optimisation: https://bugs.tryton.org/roundup/issue1627 > > <https://bugs.tryton.org/roundup/issue1627>Issue for SQL optimisation: > > https://bugs.tryton.org/roundup/issue1628 Such issue can only serve to collect links to other issues. Is this intended? So far we use roundup in an 'atomic' way, i.e. one issue per entry. Collecting several issues under one issue contradicts the workflow of roundup. Cheers -- Mathias Behrle MBSolutions Gilgenmatten 10 A D-79114 Freiburg Tel: +49(761)471023 Fax: +49(761)4770816 http://mbsolutions.selfip.biz UStIdNr: DE 142009020 PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6
signature.asc
Description: PGP signature
