Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!pt.cs.cmu.edu!andrew.cmu.edu!ba0k+ From: ba0k+@andrew.cmu.edu (Brian Patrick Arnold) Newsgroups: comp.sys.mac.programmer Subject: ROM Proc bottlenecks? Message-ID: Date: 27 Jul 89 19:00:48 GMT Organization: Mechanical Engineering, Carnegie Mellon, Pittsburgh, PA Lines: 35 Hi there, in an attempt to find the cause of a visibly slow portion of my user interface, I used MPW's performance tools to learn whether TextEdit in ROM was the culprit. The results turned out to be baffling, because I don't recognize most of the following calls (45.5% outside the segments): 120 ROMII : FMSWAPFONT 1495 0 0 11.4% 120 ROMII : ATRAP68020 1185 222 297 10.7% 120 ROMII : MEASURETEXT 1185 1 3 9.0% 120 ROMII : ITABMATCH 606 61 121 5.1% 120 ROMII : EMT1010 485 0 0 3.7% 120 ROMII : COLOR2INDEX 354 32 86 2.9% 120 ROMII : GETDEVPIX 77 30 40 0.8% The code being tested is getting text from a non-styled TE record (TEView in MacApp, in fact) and putting it into a styled TE record, and becomes visibly slow after doing it about 10 times, and unbearably slow after about 20. I don't know if I can call any of the above procs "bottlenecks", but my (and MacApp's) procs couldn't even break 2% of the time spent, claiming about 80 to 90% "outside the segments" which doesn't add up with the above. If anybody could shed some light on what these procedures are or do, and whether they have anything to do with TextEdit or MacApp, I'd appreciate your kind advice. And while I'm at it, I could say the program fragments memory like crazy, a benefit from having been written originally for a Sun-III, but minimized by some memory management code I've added between the original code and the Mac MM. The memory management code I added reduced memory allocation time by 2 orders of magnitude in other areas of the program, but the code I measured is mostly MacApp TEView or direct TextEdit calls. Clues, hints or tips? - Brian