12 Dec
2011
12 Dec
'11
9:59 a.m.
Hi,
On Dec 12, 2011, at 9:16 AM, Hamster wrote:
Hi Vincent,
Just thinking out loud about the performance-hit when WikiWords are
enabled...
I guess that there's performance-hit because the pages are processed each
time a user opens that page, right?
If so, maybe we should use a different mechanisme for the WikiWords? There
are two cases when WikiWords should be processed: (1) When a user edits a
page and adds a WikiWord to that page, and (2) when a user adds a new page
to the Wiki (all other pages should be updated). If we have a "database" of
all WikiWords in the Wiki, we would know up-font which pages we need to
update.
In both cases, the WikiWords are processed only once, and further
performance-hits should not occur(???)
Yes you're completely right.
Actually I code the WikiWord Rendering Transformation as an exercise just to prove that it
worked and as a stop gap solution to offer this feature quickly.
You're right that a better solution would be what you describe. However the problem
still remains that you'll need to map the "table of links" to the document
content being rendered. Imagine for example that for document X the table returns 2 links
called A and B. When the rendering engin renders the content as HML (for ex), our code
would need to extend/override the onWord() event and compare it to A and B to see if they
match.
So the performance gain will be the different between a contains() in a List (for checking
if it matches A and B) vs the time to do a regex match with a compiled pattern.
I have the feeling the regex match could actually be faster or very similar since if
it's implemented correctly it'll check the first letter and return if they
don't match and if it's not an uppercase letter, then check the second letter,
etc.
WDYT?
Thanks
-Vincent
WDYT?