Has anyone noticed a performance glitch in 8.4.13?

[sp...@controlq.com]

I've written a script to create thumbnails from .JPG files using TKImg and
I've noticed an anomaly when running on a compiled from source version of
8.4.13 vs the FreeBSD ports version of 8.4.11.

The script runs about 8 to 10x slower on the 8.4.13 version, and while
I've compiled on FreeBSD (and Linux and Windows for that matter) from
source any number of times, I've never seen such dramatic differences
before. While I've noted some slight differences in the TEA
build/configure environment under 8.4.13 (default paths mostly), nothing
explicit or obvious would account for the slowdown.

I have not checked this on any platform other than FreeBSD 6.1-Release at
this point.

Has anyone else noticed something similar? I was hoping to determine
whether this was a known problem before putting any significant effort
into isolating the cpu-hog ...

Cheers,
Rob.

[Donal K. Fellows]

sp...@controlq.com wrote:
> Has anyone else noticed something similar?

Yes, it's a known fault. There's that many different cases that need to
be treated carefully in the Tk_PhotoPutBlock code that trying to fix one
can degrade another. :-(

Donal.

[sp...@controlq.com]

Ahh, I see the "code of many colours", plus alpha, plus dither. Perhaps
I'll stare at this for a while and see if anything obvious pops out.
Factoring code might lead to some hierarchical optimizations, but clearly
Tk_PhotoPutBlock is pretty overloaded, and frankly my graphics skills will
need some serious dusting off prior to being able to grokk it effectively.

One thing which does arise from the comments, is to have two versions of
Tk_PhotoPutBlock, one for canvas targets and one for image targets which
does not charge image setup penalty (my app creates/scales thumbnail
images on the fly). At the risk of some uglification, and a code fork in
a wrapper for Tk_PhotoPutBlock (to isolate code changes) the general case
will be higher performance in either case. Have to look at the
implications, and how difficult to differentiate between them.

Thanks for your prompt and accurate reply, Donal. My concern is being
locked out of 8.4.13++, and particularly the 8.5/Tile stream down the
road. Having to live with an older version of Tcl is possible, but given
the evolution Tcl seems to be taking -- it is EXTREMELY undesireable to be
left behind.

Cheers,
Rob.

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Don Porter]

> Thanks for your prompt and accurate reply, Donal. My concern is being
> locked out of 8.4.13++, and particularly the 8.5/Tile stream down the
> road.

DKF forgot to mention this is already fixed for Tk 8.4.14.

--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|

[Donal K. Fellows]

Don Porter wrote:
> DKF forgot to mention this is already fixed for Tk 8.4.14.

Not forgot, couldn't remember if it had made it in. :-}

What we're really looking for is some way to build a test suite that
checks these various modes for performance nasties so we don't make this
sort of blunder in the future. Tricky to do though.

Donal.

[sp...@controlq.com]

On Wed, 12 Jul 2006, Donal K. Fellows wrote:
>
> Don Porter wrote:
> > DKF forgot to mention this is already fixed for Tk 8.4.14.
>
> Not forgot, couldn't remember if it had made it in. :-}

Thanks to both Donal, and Don Porter for the info. I'll test under 8.4.14
at the appropriate juncture, and use 8.4.11 in the meanwhile.