Wednesday, February 23, 2000

  • Macworld has about 2,000 images on its site. Most of them are not needed immediately, but some are used frequently. I ran the profiler on a rendering of the Macworld homepage under mainResponder, and found that it was spending between 1,000, and 1,300 ticks in html.getImageData(). This was at least two orders of magnitude longer than any other script took to execute.

    I think this is primarily because it is searching subtables for images. (Macworld’s site stores images in sub-tables under the #images table.) At first, I went overkill, wanting to reorganize the #images table, and override the imgeRef() script so that it would do a binary, rather than linear search. But then I realized that searching for an image didn’t have to be fast every time, and that if I cache the image’s address, it would be much faster, except for the first time I rendered an image.

    All seemed fine, until I discovered (to my initial surprise) that if you pass it an address, html.standardMacros.imageRef() assumes that images are not nested inside the images/ folder- rather, they are all at the top level of images/. (This makes sense, because imageRef() has no idea what site is pulling the image in, or where it’s supposed to be.) So much for simply overriding imageRef() and caching image object addresses.

    It looks I’ll have to parse the HTML that html.standardMacros.imageRef() returns, and fix the path myself… Somehow this seems strange to me. (I realise that this looks dense, but I sense the need for another, usually invisible, abstraction layer here.)

  • Once again
  • Heard on 3rd Rock: “Bless you for being such a jerk.” (Don’t worry- I’m not talking about anyone in specific.;): Smile!)

Comments are closed.