My point is that if I'm going to optimize anything, this is the sub to spend my time on. The other two candidates I've already tweaked, and even if I doubled their performance I'd still get only a modest gain. A clever insight on this sub could make a much bigger difference.

%Time ExclSec CumulS #Calls sec/call Csec/c  Name
 48.8   20.83 20.710 130000   0.0002 0.0002  FTS::printto
 17.5   7.499  7.490  10000   0.0007 0.0007  FTS::addstring
 15.3   6.569  6.450 120000   0.0001 0.0001  FTS::assign
 6.77   2.892 42.220  10000   0.0003 0.0042  main::__ANON__
 2.55   1.090 43.310  10002   0.0001 0.0043  Benchmark::__ANON__
 2.44   1.040  1.030  10000   0.0001 0.0001  main::cleverlinks
 2.20   0.940  8.410  10000   0.0001 0.0008  FTS::parsehandle
 1.45   0.620  0.610  10000   0.0001 0.0001  IO::File::open
 1.38   0.590  1.650  10000   0.0001 0.0002  IO::File::new
 1.38   0.590 10.620  10000   0.0001 0.0011  FTS::parsefile
 1.03   0.440 11.410  10000   0.0000 0.0011  FTS::new_fromfile
 0.94   0.400  0.390  10000   0.0000 0.0000  FTS::new
 0.77   0.330  0.320  10000   0.0000 0.0000  Symbol::gensym
 0.42   0.180  0.480  10000   0.0000 0.0000  IO::Handle::new
 0.07   0.030  0.010  20000   0.0000 0.0000  IO::Handle::DESTROY

Here's another thought: how about not calling your printto() and assign() methods quite so often?

There's overhead in calling the subs in the first place. Doubly so for method calls. Cut down on the number of calls.

Examine your algorithms to determine why it's necessary to call FTS::printto()/assign() an order of magnitude more times than anything else in your program. Can the work be put off, done in batches? Can you leave yourself helpful references in the data so that less looping/searching is necessary? (Fewer arrays, more hashes). Is there an opportunity to memoize functions somewhere? Can you prepare the data better during FTS::parsefile (or new_fromfile or something) so that it's more easily dealt with later on?

Beware of premature optimization