Ответ на сообщение «Re: Progress indicator for :TOhtml command», присланное в 19:39:15 05 июня 2010, Суббота, отправитель Benjamin Fritz:
A small benchmark for your and mine scripts:
user system cpu total Relative
mine, no progress 93,07 10,82 99% 1:44,06 + 5%
mine, only per cents and bar 95,77 10,92 99% 1:46,94 + 8%
mine, %, bar and lines 125,59 14,80 99% 2:20,83 +43%
2html from vim-7.2.303 97,34 1,16 99% 1:38,64 + 0%
your 2html, no progress 77,31 0,99 99% 1:18,55 -20%
your 2html, with progress 100,57 1,20 99% 1:42,76 + 4%
Commands:
# mine, no progress
time vim messages -c 'set ft=messages | execute "%FormatCommand format html" |
qa!'
# mine, only % and bar
time vim messages -c 'set ft=messages | let g:formatOptions={"ShowProgress": 1}
| execute "%FormatCommand format
html" | qa!'
# mine, %, bar and lines
time vim messages -c 'set ft=messages | let g:formatOptions={"ShowProgress": 2}
| execute "%FormatCommand format
html" | qa!'
# 2html, your with progress and 2html from vim-7.2.303
# Difference is that in second case I created a symlink to your file in
# .vim/syntax directory
time vim messages -c 'set ft=messages | execute "TOhtml" | qa!'
# your 2html, with progress
time vim messages -c 'set ft=messages | let g:html_no_progress=1 | execute
"TOhtml" | qa!'
You can download messages file here: (1,1M uncompressed, 77K compressed):
http://kp-pav.narod.ru/messages.xz
My script is located here (see version 1.2):
http://www.vim.org/scripts/script.php?script_id=3113
I do not know what exactly is a problem, but your progress is too slow.
Текст сообщения:
> On Thu, Jun 3, 2010 at 10:03 PM, Benjamin Fritz <[email protected]>
> wrote:
> > This version is still not fast enough though. It is about 30% slower
> > when the progress bar is enabled than when it is disabled. While I
> > consider it a good tradeoff in most cases, we could certainly make it
> > better.
> >
> > It would probably be faster to pre-calculate the line numbers needed
> > to advance the progress bar rather than doing a bunch of
> > floating-point math every cycle.
>
> I've attached a new version which pre-calculates the (integer) line
> numbers needed to advance the progress bar. Now all the floating point
> math is done once, up front.
>
> The difference is not really very perceptible. I timed the execution
> on two files. First, I did the 5148-line autoload/phpcomplete.vim
> script. Timings were as follows on my laptop:
>
> progress disabled:
> average: 46 seconds
>
> floating-point progress:
> average: 61 seconds
> slowdown: 15 seconds longer than without progress bar
> percentage: 33% longer than without progress bar
>
> precalculated progress:
> average: 62 seconds
> slowdown: 16 seconds longer than without progress bar
> percentage: 35% longer than without progress bar
>
> Next I did a 33258-line C code file:
>
> progress disabled:
> average: 691 seconds
>
> floating-point progress:
> average: 716 seconds
> slowdown: 25 seconds longer than without progress bar
> percentage: 4% longer than without progress bar
>
> precalculated progress:
> average: 711 seconds
> slowdown: 20 seconds longer than without progress bar
> percentage: 3% longer than without progress bar
>
> I also did a number of very small sections of files (my usual use case
> for 2html) and did not notice any significant slowing; it only takes
> 1-2 seconds longer for a 100 or 200 line selection.
>
> I take a few things from this.
>
> First of all, I don't think we'll get much performance improvement
> with this method. I do not know whether it is setting the status line
> and redrawing it, or whether it is the use of the object-oriented
> style functions, but it would probably require a different approach to
> get a significant speedup. I certainly like the look a lot better than
> the echo method, even if we could get echon working. Is a 10-20 second
> slow-down acceptable on large numbers of lines, if the normal
> execution time is measured in minutes anyway? To me, it certainly is.
> If something is going to be taking more than a few minutes, I want a
> progress bar to tell me whether it's worth letting it continue. Since
> the slow-down can be significant for midsize files, we will certainly
> need to mention in the :help that disabling the progress bar will make
> the conversion faster. Maybe we should only show the progress bar
> after some amount of time has elapsed? We could suppress the
> redrawstatus until 10 seconds have passed, or something like that. Any
> thoughts?
>
> Secondly, the precalculated version is not really any faster than the
> full floating-point calculation every cycle. I don't really have an
> opinion of which method gives more readable code. Does anyone else
> have any opinions on which version to keep? I think it would be
> possible to do away with floating point calculations entirely using
> the precalculated version; currently floating point is only used in
> the calculate_ticks function. This might be desireable so that we can
> remove the dependence on the +float feature, which is not marked with
> a "smallest version" indicator in :help +feature-list. This apparently
> means it is "system dependent". Does this mean float is pretty much
> always included, unless it is explicitly removed? How common are Vims
> without floating-point support? I already added use of the split()
> function, which was added in version 7, so this won't work on really
> old Vims...but do we want to support Vim 7.1 and earlier?
>
signature.asc
Description: This is a digitally signed message part.
