can you post your model?
there may be places (for example references and validators) which force the
instantiation of lazy tables. Code needs to be rearrange to take advantage
of lazy tables.
Here are my benchmarks (admittedly extreme and not typical scenario) but I
do expect a speedup:
import time
n = 1000
migrate = False
fields = [Field('f%i' %i) for i in range(20)]
t0 = time.time()
db = DAL('sqlite://storage.sqlite',migrate=migrate)
for k in range(n):
db.define_table('t%s'%k,*fields)
print 'no lazy time:',(time.time()-t0)/n
t0 = time.time()
db = DAL('sqlite://storage.sqlite',lazy_tables=True,migrate=migrate)
for k in range(n):
db.define_table('s%s'%k,*fields)
print 'lazy time:',(time.time()-t0)/n
# output
# no lazy time: 0.00195078992844
# lazy time: 4.85169887543e-05
On Saturday, 18 August 2012 04:58:21 UTC-5, David Marko wrote:
>
> I have redesigned one of my app by moving requires into Field definition,
> and setup the lazy_tables=True ... and benchmarked difference(before and
> after trunk version) using apache benchmark but cant see any difference for
> home page which dont require any table ... so I expect speedup here. Both
> AB gives me cca. 32req/sec
>
> David
>
> Dne sobota, 18. srpna 2012 5:00:44 UTC+2 Massimo Di Pierro napsal(a):
>>
>> There are two major speed improvements in trunk and I am not sure whether
>> they should go in web2py 2.0 next week.
>>
>> 1) Lazy table (based on ideas from Bruno).
>>
>> db = DAL(...., lazy_tables=True)
>> db.define_table('person',Field('name'))
>>
>> the table is instantiated only when db.person is accessed.
>> So with some care:
>>
>> Field(...., requires=....) # LAZY (good)
>> db.table.field.requires = ... # NOT LAZY (bad)
>>
>> Field('other','reference table') # LAZY (good)
>> Field('other',db.table) # NOT LAZY (bad)
>>
>> this may be a big speedup.
>>
>>
>> 2) There is a new implementation of class Storage. This is a most
>> accessed object within web2py and now it is 10x faster.
>> Yet I am not sure if this breaks something.
>>
>>
>> It would be great if you could try the nightly build (or trunk) and
>> report if you experienced any problem.
>> It would be even better if you could run some benchmarks of your code
>> before and after the changes suggested at 1).
>>
>> Massimo
>>
>>
>>
>>
>>
>>
--
