diff options
Diffstat (limited to 'doc/bugs/Buggy_dependency_graph.mdwn')
-rw-r--r-- | doc/bugs/Buggy_dependency_graph.mdwn | 80 |
1 files changed, 0 insertions, 80 deletions
diff --git a/doc/bugs/Buggy_dependency_graph.mdwn b/doc/bugs/Buggy_dependency_graph.mdwn deleted file mode 100644 index 116a2aea4..000000000 --- a/doc/bugs/Buggy_dependency_graph.mdwn +++ /dev/null @@ -1,80 +0,0 @@ -I think there is a problem in my "dependency graph". As an example, -[here](http://poivron.org/~nil/misc/ikiwiki_buggy_index) is the index -ikiwiki generated for [my site](http://poivron.org/~nil/misc/ikiwiki_buggy_index) -(note that the site changed since this index was generated). - -Some **HUGE** dependencies appear, clearly non optimal, like - - depends = A| B | A | C | A | D | A | E | A | F | A | G | .... - -or - - depends= A | B | C | D | A | B | C | D | A | B | C | D | .... - -Couldn't isolate the cause, but some sources for this problem may be: - -* related to the img module -* easily observable in my sire because one of my pages includes 80 resized images - -Other special things in my templates and site: - -* a sidebar with \[[include pages="notes/\*" template=foo]] while notes.mdwn has - a \[[include pages="notes/*"]] and uses the sidebar; removed it, doesn't change -* a template (biblio.tmpl) calling the "img" plugin with a template parameter as the - image filename; removed it, doesn't change -* some strange games with tags whose page calls a "map" directive to show other tags - shile tags are also used in tagclouds (in the sidebar and in the main pages) -* ... - -I observed these problems (same *kind*, I didn't check in details) on - -* ikiwiki 2.00gpa1 + v5.8.4 + Debian 3.1 -* ikiwiki 2.3 + v5.8.8 + Ubuntu 7.04 - -I can think about reducung the size of my wiki source and making it available online for analysis. - --- NicolasLimare - -> As long as these dependencies don't grow over time (ie, when a page is -> edited and nothing changed that should add a dependency), I wouldn't -> worry about them. There are many things that can cause non-optimal -> dependencies to be recorded. For one thing, if you inline something, ikiwiki -> creates a dependency like: -> -> (PageSpec) or (file1 or file2 or file3 ...) -> -> Where fileN are all the files that the PageSpec currently matches. (This -> is ncessary to detect when a currently inlined file is deleted, and know -> the inlining page needs an update.) Now consider what it does if you have -> a single page with two inline statements, that inline the same set of -> stuff twice: -> -> ((PageSpec) or (file1 or file2 or file3 ...) or (PageSpec) or (file1 or file2 or file3 ...) -> -> Clearly non-optimal, indeed. -> -> Ikiwiki doesn't bother to simplify complex PageSpecs -> because it's difficult to do, and because all they use is some disk -> space. Consider what ikiwiki uses these dependencies for. -> All it wants to know is: does the PageSpec for this page it's considering -> rebuilding match any of the pages that have changed? Determining this is -> a simple operation -- the PageSpec is converted to perl code. The perl -> code is run. -> -> So the total impact of an ugly dependency like this is: -> -> 1. Some extra data read/written to disk. -> 2. Some extra space in memory. -> 3. A bit more data for the PageSpec translation code to handle. But that -> code is quite fast. -> 4. Typically one extra function call when the generated perl code is run. -> Ie, when the expression on the left-hand side fails, which typically -> happens after one (inexpensive) function call, it has to check -> the identical expression on the right hand side. -> -> So this is at best a wishlist todo item, not a bug. A PageSpec simplifier -> (or improved `pagespec_merge()` function) could be written and improve -> ikiwiki's memory and disk usage, but would it actually speed it up any? -> We'd have to see the code to the simplifier to know. -> -> --[[Joey]] |