Hi everybody, Just to follow up, upgrading from tryton 2.6 to tryton 2.8 improved the total speed to pay an invoice + ship a shipment + finish a sale by 5 to 10 times without any algorithm changes in my custom modules (ie. I just needed to upgrade them to 2.8). It was taking 70+ seconds(all combined) to perform those operations and now it is 5 to 10 times faster than that which is much more usable. So... thank you for the speed improvements in 2.8 they were extremely helpful.
-Ian On Tue, Apr 23, 2013 at 11:54 PM, Guillem Barba Domingo < [email protected]> wrote: > > El 23/04/2013 22:32, "Albert Cervera i Areny" <[email protected]> va > escriure: > > > > > A Dilluns, 22 d'abril de 2013 11:24:15, Udo Spallek va escriure: > > > > > We could try a test script and measuring the pystones. > > > > > It is a whetstone[1] implementation for python and found in the stdlib > > > > > *test*. > > > > > The idea is to run a fixed script on an individual computer hardware > and > > > > > measures the run time and a ratio compared to a reference computer: > > > > > >>> from test import pystone > > > > > >>> time_running, mypystones = pystone.pystones() > > > > > >>> mypystones > > > > > 125000.0 > > > > > My computer has 125000 pystones or 125 kpystones. > > > > > If I have a test which takes 1.4 seconds to run on my hardware, I can > > > > > calculate the kilo pystones for the test: > > > > > >>> kpystones = mypystones * 1.4 / 1000 > > > > > >>> kpystones > > > > > 175.0 > > > > > The test with 175 kpystones are comparable on different computers - in > > > theory. > > > > > On the other hand is the performance of the Tryton server affected by > > > > > many different technologies, not only cpython. > > > > > So I don't know if we have a chance to compare the timings of the test > > > > > results at all. > > > > I don't think that works. We're talking about CPU, RAM, HD Speed, > running applications, etc, etc. > > I think it could be interesting to have the time of execution of the > diferent tests and collect them in a wiki page with the configuration of > the server where the test has veeb executed. > > It could be a table with the diferent cases as columns and the > configuration and test times in rows. > Configurqtions are CPU, ram, cache but also version of postgres and other > implied technologies and some params in their configurations. > It's impossible to take in account all variables but ut could help to > identify what are the most important. > > Guillem Barba >
