Wednesday, December 23, 2009

Re: Best practice and enhance performance duration of vimscript

epanda wrote:
>> I'm not sure what exactly you're trying to achieve here -- mostly the
>> source of the l:lineToChange -- is this from some larger loop? The
>> reason it's confusing is that after you've gone through the loop once,
>> I'd expect that TO_SUB_WITH_KEY is no longer in the string, so
>> subsequent passes through the loop look like they're just appending the
>> same line (which, btw, I'd perform with
>>
>> put=line
>>
>> instead of via normal mode.)
>>
>> My first thought would be to do fewer substitutes, which could be done
>> if your hashes are nested, so you have a double-dereferencing.
>> Something like
>>
>> :%s/TSWK1\|TSWK2\|TSWK3/\=s:hash[submatch(0)]/g
>>
>> or, if you have a bunch of keys, you might be able to do something like
>>
>> :let @/=join(keys(s:hash), '\|')
>> :%s//\=s:hash[submatch[0]]/g
>>
>> (you might have to escape the keys if there are funky regexp
>> metacharacter values in the hash keys)
>>
>> -tim
>
> Tim, see my first post, l:lineToChange is defined before the loop on
> my hash.

Yeah, I read that, but unless the values of your key:value pairs have
additional TSWK values in them to be later replaced, your first pass
through the loop removes everything your later passes are looking for,
so they're moot (and time-consuming)

> I prefered concat my xml line before loop and doing mapping
> (substitute) into the loop thinking it was faster (but not after
> measurement)

I've found that in general, if your file has lots of lines rather than
one long single line, Vim tends to play better/faster with it. I expect
it has to do with how much needs to be rejiggered in memory with each
change, and how much has to be allocated for a single line. If you have
short lines, small allocations and small copies happen per-line. If
everything is on one line, you have to have a large buffer into which
you copy the modified long-line and perhaps copy that large quantity
multiple times per match.

> I didn't know if exec 'norm o' take a long time, thank you for your
> response.

This has been my gut feel, that changing modes takes a fair bit of
context preservation and restoration which in turn takes time. Glad to
see this hopefuly helped you speed it up.

> If you have other advises or link I will be glad to apply them.

Perhaps if you describe what you're trying to achieve rather than the
methods you're trying to achieve them, a wildly different solution could
be feasible. Particularly if the command can be executed across a
buffer or a range of lines instead of a string-variable.

-tim


--
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php

No comments:

Post a Comment