>>>>> Markus Hoenicka <[email protected]> writes: > "Ottaway, Jim" <[email protected]> was heard to say: >> You could try profiling the planner package to see what is taking up all >> of that time: >> > thanks for making me aware of these profiling commands. This is just > what I was looking for.
> The results are a bit strange though. Planner itself barely takes a > couple of seconds. Therefore I also instrumented the muse package, > which does the publishing after all. This is what I get (only the top > 35 or so entries are shown here): This one looks a bit suspicious: > muse-publish-mark-up-tag 1 438.902 438.902 Do you have a <markup function=...> tag in a file somewhere with a function that takes a long time? > What intrigues me is that a bunch of muse publishing functions like > muse-project-publish-file are called 979 times, which is the number of > muse files in my project. That is, muse spends approx. 7 minutes in > files which don't need to be published at all. If I look at the > timestamps in my output directory, I can verify that muse updates only > those files which were actually modified, e.g. two files in the test > shown above. Is this some problem of my particular setup, or is > planner/muse supposed to work this way? Yes, it is supposed to work this way: muse-publish-file does the check to see if FILE is newer than the published file, so it gets called no matter what, but nothing is done if FILE is not newer [unless FORCE is non-nil]. Yours sincerely, -- Jim Ottaway _______________________________________________ Planner-el-discuss mailing list [email protected] https://mail.gna.org/listinfo/planner-el-discuss
