Hello Vyacheslav,
today I had again some time to look at the problem and it turned out,
that the problem was partly in Weblocks, partly in ASDF :
Weblocks computes on each client request the path of the application,
which (if i understand correctly, if not set by the developer
explicitly) is calculated from the path of the ASDF-system to which
the application belongs. For that Weblocks calls asdf:system-
definitions-pathname, which on it's turn traverses all known
directories known to ASDF to search and does a PROBE-FILE for .asd
files with the name of the system searched. And that can take a while.
Not knowing if this is an intendet behavior of Weblocks I implemented
a small function, which memoizes the .asdf locations per system, which
I turn on before loading Weblocks. Then - the demo responds allways in
less than a second.
Below is the code I use - if you find that there are also other users
affected by this behavior, you could include it in the distribution.
With best regards
Plamen
(defvar *asdf-cache* (make-hash-table :test #'equalp))
(defun cached-sysdef-central-registry-search (system)
(let ((result (gethash system *asdf-cache*)))
(unless result
(setf result (some (lambda (x) (funcall x system))
(rest asdf:*system-definition-search-
functions*)))
(when result
(setf (gethash system *asdf-cache*) result)))
result))
(defun cache-asdf-locations ()
"Installs an ASDF search function for caching the location of ASDF
systems found"
(setf asdf:*system-definition-search-functions*
(pushnew 'cached-sysdef-central-registry-search asdf:*system-
definition-search-functions*)))
(defun uncache-asdf-locations ()
"Uninstalls an the ASDF search function for caching the location of
ASDF systems found"
(clrhash *asdf-cache*)
(setf asdf:*system-definition-search-functions*
(remove 'cached-sysdef-central-registry-search asdf:*system-
definition-search-functions*)))
On Mar 20, 5:41 pm, Vyacheslav Akhmechet <[email protected]> wrote:
> On Fri, Mar 20, 2009 at 12:17 PM, Plamen Stamov <[email protected]>
> wrote:
> > But, the first suspectible thing I see is a bunch of warnings from CL-
> > CONT (below is my compile-log from LispWorks), and a warning from
> > Fare's Matcher, that multiple-value-call is inefficient...
>
> CL-CONT (and Fare Matcher) are only used in very specialized cases.
> Most of the operations you described above don't depend on these
> facilities, so I don't see how they could cause an overall slowdown
> (especially to such a degree).
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"weblocks" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/weblocks?hl=en
-~----------~----~----~----~------~----~------~--~---
