Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

History Slow-down

Alex
2004-11-24
2013-04-24
  • Alex
    Alex
    2004-11-24

    Hello Dhamma-vicayers,

    Unanimously, you desire the ability to 'go back' in browser history to the hits page and perhaps keep a record of the previous query(s).

    My solution is to submit the query via HTTP/GET which forces the browser to reload a page with a new URL such as this:

    file:///CDROM/ATI/search.html?query=Buddha&page=5

    This is very similar to the way Fluid Dynamics and Google work. When you enter a query into:

    http://www.google.com

    The hits page's URL is something (more complex than) this:

    http://www.google.com/search?q=Buddha

    This URL then servers as a token (milestone if you like) for the browser. It is stored in the URL history and can be book-marked if desired. Unlike a web based search engine, Vicaya performs the search only after the page and, more specifically, the applet have been loaded.

    What this means is that when the user enters a query and clicks "Search", the display will seem to go blank for some time (depending on the speed of the environment) until the applet has loaded.

    Aside from a "please wait" popup, I have played with a few tricks to increase the perceived responsiveness. Loading the applet while the user enters a query helps by caching the applet, but the applet still has to reload when "Search" is performed.

    The performance hit is most significant on the Mac. I've got a three year old 700Mhz G3 iBook with 512Mb RAM running Mac OS X 10.2.8 (JVM 1.4):

    Safari
    first time: 20 seconds
    second time: 4 seconds
    refresh page: 3 seconds

    Firefox 1.0
    first time (launch): 28 seconds
    first time (already): 23 seconds
    second time: 13 seconds
    refresh: 20 seconds

    Keep in mind, the Mac uses a very poor Java Virtual Machine. On Windows, Linux, and Solaris, there are several competing versions. Also, there may be some optimizations I have not yet tried (compilation flags, etc). I will keep working on this and give you something a bit more stable.

    The way the previous release worked was to open a single page. The user could only enter a query into the applet after the applet had fully loaded. Once the applet was loaded, submitting a query worked directly with the current applet in the same page. The minimal delay was due to the search operation without a reload penalty. In that model, there is no way to store the query or the hits once the page has been cleared.

    In the new model, the user can enter a query without waiting for the applet to load, but must wait to view the hits. The query and hit state will be stored in the browser history.

    I believe these are the best solutions to the over-all problem. What are your feelings about each (or other solutions)?

     
    • Alex
      Alex
      2004-11-24

      JAR Compression

      The Java applet contains about a hundred class files. All of these files are packaged into a single file called a JAR (Java archive). When compressed, Vicaya.jar is about 400K, otherwise it is almost 800K.

      I have re-run the above tests with an uncompressed JAR.
      Firefox loads the applet in about 15 seconds in all cases. The results for Safari remain the same.

      Compiler Optimization

      Compiling with optimize (true) and debug (false) without compression gave a small boost:

      Safari
      first time: 17 seconds
      second time: 3.5 seconds
      refresh page: 3 seconds

      Firefox 1.0
      first time: 25 seconds
      second time: 13 seconds
      refresh: 2 seconds

      These numbers are based on only a few test runs.

      Other optimization possibilities:

      o) use a profiler
      o) take advantage of Swing threading
      o) turn off double buffering
      o) load the JEditorPane in another thread
      o) patch thread-safety (sun.com)
      o) get rid of JEditorPane, go back to AWT
      o) keep Lucene in separate JAR

      This is the first time I've used JFC/Swing. I'm very open to other ideas. I expect to get this release stablized shortly, then I'll add all the code to CVS.