Hi Jeremy,
Thanks for your advice.
- In this case, because the web application is in one file, everytime
a page is displayed, Links is type-checking, optimizing, and
type-checking again. Maybe splitting the application could improve its
performance.
- Based on the SQL generated in the log, database access seems not to
be the problem at all, at least all the SELECT statements are under
0.01s. However, is there any way to know how much time the INSERT,
UPDATE, and DELETE statements take?
- What is refered as "caching" is like a way to detect if Links already did
the type-checking and optimization routines to prevent doing them
again? in the same subject, what exactly the "optimization" phase does?
Thanks,
Gabriel
Quoting Jeremy Yallop <[EMAIL PROTECTED]>:
Quoting G Tellez <[EMAIL PROTECTED]>:
http://frege/~gabriel/linksPetStore/test33.links
[...]
- Jeremy, I'm working on frege at the moment, how can I turn on the
"measure_performance" flag?
You can set it in the config file. Add
measure_performance=on
to
~gabriel/public_html/bin/config
When I run (a copy of) your program with "measure_performance" set I
see the following in the log file:
parse : 0.064004 seconds taken
parse : 1606080 words allocated
type : 3.132197 seconds taken
type : 184435887 words allocated
optimise : 0.500031 seconds taken
optimise : 50725604 words allocated
type again : 1.656103 seconds taken
type again : 85398936 words allocated
which suggests that a significant proportion of the time is due to type
checking and a non-trivial proportion on "optimisation". Eliminating
this overhead via some form of caching should noticeably improve the
performance.
Jeremy.
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
_______________________________________________
links-users mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/links-users
