This is version . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]
TitleClicking on 'more info' on takes a very long time
Date24-Sep-2005 01:28:46 EEST
Bug criticalityLightBug
Browser version
Bug statusNewBug
PageProvider used
Servlet Container
Operating System
Java version

Clicking on 'more info' on takes a very long time.

I would like to profile what the problem is and maybe then fix it. Therefore I need the complete wiki-data-directory of the site Is there a way to get this? Or could some one create a tgz/zip file?

-- KeesKuip

Ok. Here's a snapshot of the latest file. I will also put it on JSPWikiSnapshot.

OK, here are the first results. (I already posted yesterday but I thought my measurements were wrong so I removed them late at night).

Here's how I test:

  • undeploy JSPWiki
  • deploy war
  • start profiler (which starts tomcat)
  • call page Main
  • start profiling the cpu.
  • call page 'More info' of Main-page
  • stop profiling (measurement 1)
  • call page Main
  • start profiling the cpu.
  • call page 'More info' of Main-page
  • stop profiling (measurement 2)
  • .. and the same way for (measurement 3)

I measure 262883/263008/269400 msec. (measurement 1/2/3) for jspwiki v2.2.33.

I notice a hotspot in I changed the method so that it would read more than 1 byte/char at one time and write more than 1 byte/char at one time. This resulted in a measurement of 53657/34565/35238 msec.

The result is an improvement in speed of 5-7 times the orginal. Not bad for a first run!. I attached the new (It is backward compatible).

-- KeesKuip

More results.

In the snapshot after the fileutils-patch I noticed a hotspot in loading property files. When I call page 'More Info' of the page 'Main' I see that there are 2419 invocations to properties.load(). That must be wrong!

So I debugged it a little bit and saw that very often the propertyfile is asked that had just been asked before. So I decided to cache only (in a safe way) the last loaded propertyfile in That resulted in 150 invocations to properties.load(). Much less, but I smell bad programming here.

The measurements are:
before: 53657/34565/35238 msec (see previous post)
after: 19417/19251/18634 msec.
An improvement of almost 2x.

So patch 1 and 2 together give an improvement in cpu-time of about 13x. (Mind you: This patch does give a 2x improvement but calling load-properties 150x for 1 page just smells like something is wrong in the design.)

This patch is downward compatible.

More to come.

-- KeesKuip.

The next culprit was the PageSizeTag. It calculates the pagesize in a very cpu-intensive manner. The pagesize is then initialized in wikipage.setSize() so the next time it is known immediately.

A wikipage is loaded with the "PageManager" that lets a "FileProvider" implements its "getPageInfo()" method. This getPageInfo() returns a WikiPage. So why not set the size of the WikiPage in that method? I did it for VersioningFileProvider and got the following measurements:
before: 19417/19251/18634 msec. (see previous post)
after: 9330/8021/7890 msec.
An improvement of more than 2x.

So all patches together give an improvement in cpu-time of more than 30x.

This patch is downward compatible. The patch is also done in So the attached file combines patch 2 and 3.

-- KeesKuip

Oef, A major setback!

I changed the FileUtils.copyContents() (see patch1) twice. One for an InputStream and once for a Reader. The changes were both perfectly allowed and good. But there is a reader TranslatorReader which has not implemented its contract as a Reader good. The results are that with the changes in patch1 I get empty pages. So for now I've reversed the change in copyContents of the Reader.

The performance improvement of patch1 will now be 4x ! I measure 66529 msec.

I've already patched TranslaterReader, but it will not perform any better. The problem is this: The CheckVersionTag wants to now if a page exists with a certain versionnumber. So it only want's to know if a page exists but then the complete page is read in memory and translated. This is just bad! The pageExists takes 56222 msec of the total of 66529 msec!!!!

Just look at the profile for this problem: profile.png

-- KeesKuip

Kees, don't worry. The 2.3 translator works far better with respects to your first issue. Don't worry about it too much. The latter is a problem, I admit. It is easily fixed by making the call to pageExists() use the pageExists( page.getName() ) instead of just page - this way any existence of the page is checked.

-- JanneJalkanen

OK, your right! If I check if the pageExists(page.getName()) AND verify that the version number is smaller then we can be pretty sure that pageExists(page.getName(), version) exists.

I think The performance gain would then be back to 30x. Which would be nice because the frontpage gets defaced quite often and it takes a long time to de-deface it.

-- KeesKuip.

First many thanks for improving the speed of JSPWiki, I am very happy about this! After making these fixes can you perhaps check whether similar bottlenecks exist in the page preview or page save actions? Under JSPWiki 2.2.28 or 2.2.33 these seem to be highly variable, and sometimes taking very long, which is very annoying in the process of editing (especially when waiting for preview to fix unwanted CamelCase). On the site this may be attributed to concurrency issues, but on our test intranet site the problem occurs as well and concurrency can be excluded. -- Gregor Hagedorn, 2005-10-04

I've uploaded with the new (simple) pageExists(). Could you check that method Janne? because I removed a lot of code that maybe I didn't understand correctly.

The results are : 3033/3135/2406 msec.

Thats 80x faster as my first measurement. (wow)

Could you please delete/forget because it doesn't function wel with TranslaterReader?

Gregor, you say concurrency can be excluded but there's Lucene running in a separate thread. Is that maybe what you see? I'll see if I got time to profile some more.

-- KeesKuip

Just a quick note... Pleasepleaseplease start posting diffs instead of new files. These are nearly worthless to me, as I need to manually check what happened, and for a large file such as this is hard. And if something is hard, I am unlikely to be bothered, no matter what it does. I only have limited time to work on JSPWiki. I'll look into this sometime in the future.

With Eclipse, for example, creating a diff (or in Eclipse-talk, a patch) is trivial. Choose Team->Create Patch.

-- JanneJalkanen

Ok, point taken. I will create some patch files for you tonight. Against what version? Are you using Linux? Yes, than you can use 'meld' (sourceforge) as an excellent merge tool.

-- KeesKuip

Add new attachment

Only authorized users are allowed to upload new attachments.

List of attachments

Kind Attachment Name Size Version Date Modified Author Change note
java 8.7 kB 3 02-Oct-2005 12:53 KeesKuip
VersioningFilePageExistPatch.p... 3.4 kB 1 15-Oct-2005 18:03 KeesKuip
java 20.1 kB 2 02-Oct-2005 12:38 KeesKuip
VersioningFileProvider.patch 1.4 kB 1 05-Oct-2005 19:16 KeesKuip
java 62.7 kB 1 04-Oct-2005 19:58 KeesKuip
WikiEngine.patch 0.3 kB 1 05-Oct-2005 19:16 KeesKuip
profile.png 84.7 kB 1 02-Oct-2005 14:20 KeesKuip
« This particular version was published on 05-Oct-2005 10:18 by