Quoting G Tellez <[EMAIL PROTECTED]>:
- 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?
Yes; if you turn on the cache_programs option, it *should* store the
type-checked, optimized code after doing it once & use that on future
hits. It should also detect when the file changes and invalidate the
cache. I say "should" because I haven't looked at that stuff in a
while. Let me know if you have any problems with it, I'd like to make
sure that code works well.
- 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?
As for the SQL queries: what can happen is that a loop like this can
fail to "join":
for (var x <- table1)
for (var y <- table2)
[e]
You'd hope this would form one query over the two tables, but for lots
of reasons (bugs, limitations) it may not. When you look at the error
log, then, you'll see lots and lots of queries (corresponding to the
inner for loop), which individually might execute quickly, but it's
very inefficient to fetch the data this way.
I strongly suspect this is what's happening to you. I doubt it's the
updates or inserts. Check whether you have bajillions of requests in
the log & let us know...
Ezra
--
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
