[TxMt] Performance issues

[David Powers]

On a slightly less theoretical note - I have added ctrl-option-cmd-s to 
the Experimental bundle as "Strip Matching Lines" to make working around 
this easier.  It can easily be modified (or possible extended) to do 
arbitrary replacement as well.

-David

Aristide Grange wrote:
>> On 27/5/2006, at 16:03, Aristide Grange wrote:
>>
>> > Thank you for having explained me how to solve this stupid-but-big
>> > problem with search/replace in TextMate! [...]
>>
>> Just FYI the problem comes not from stupid code but from data
>> structure trade-offs.
>
> Thank you for your very interesting explanations about the data 
> structure you use. My intervention on the topic was initially 
> motivated by the fact that Chris mentioned the same (stupid) problem 
> on a 3.7MB XML file:
>
>> The big mistake was to try and do a Find/Replace of all ">" with ">\n".
>> Whoah. It's been using all the CPU and beachballing for over 30 
>> minutes now,
>> with no obvious way to interrupt it...
>
> From my point of view, the problem of Chris was including two 
> independant matters: 1. slow global replacement; 2. global reparsing. 
> I was surprised that your reply to him (well, the kind one) focused 
> almost only on parser considerations. It was not perfectly clear for 
> me that your promise of future improvements on "half a dozen other 
> things which do affect the performance" included the one I care about. 
> So, I thought it was necessary to insulate the first problem, with 
> which I have to deal on a daily basis: global replacement on plain 
> text. Obviously, I knew it had "nothing to do with the language 
> parser": it was precisely my point...
>
> Then, Paul came with a great solution to this very problem: filter the 
> document through a magic perl command. Since them, I am happy, and I 
> guess TextWrangler will not encuber my dock for a long time now.
> But his reply makes a second (probably stupid too) question to pop 
> into my mind: since there is such a performance issue with the builtin 
> global replacement of TextMate, why not just delegate the work to 
> perl, directly from the shiny and so convenient Find window? And if, 
> for some reason, it is not always possible, why not offer this as an 
> option through some cute check box?
>
> Concerning the "marketing" considerations of Daniel, I second that. My 
> own experience, as an old BB et al. registered user, is the following: 
> in the past, I have given TextMate at least three (too) short tries. 
> Each time, I thought: "it is not for me, because 1. there is no 
> incremental search; 2. global replacement is too slow". The drawback 
> with TextMate is that its real superiority and its amazing features 
> are not very prominent. This "tact" has several very important 
> advantages too, e.g., the interface is not bloated and the learning 
> curve is so smooth. But I have had to force me to try TextMate during 
> one plain week *before* I finally fall in love with it. BTW, I don't 
> remember if I registered before or after I accidentally discovered it 
> does offer incremental search (the manual is rather allusive on this 
> point). So I think it would be a killer marketing idea to help the 
> switchers to figure out how they can use TextMate as efficiently as 
> their favourite text editor. Apple has made something like that for 
> the Windows users (and we all know that Apple never makes any 
> marketing error ;-). Perharps some dedicated annex in the documentation?
>
> Cheers,
>
> A.
>
>
>
> ______________________________________________________________________
> For new threads USE THIS: textmate at lists.macromates.com
> (threading gets destroyed and the universe will collapse if you don't)
> http://lists.macromates.com/mailman/listinfo/textmate