57232Re: Progress indicator for :TOhtml command
- Jun 6, 2010Ответ на сообщение «Re: Progress indicator for :TOhtml command»,
присланное в 13:03:23 06 июня 2010, Воскресенье,
Yes, buffer switching is the problem: attached patch uses my technique (save
everything in a list, not in a buffer) and here are the results:
1:05,09 w/o progress
1:19,67 w/o progress
1:44,74 with progress
1:03,51 w/o progress
1:05,08 with progress
Apply patch to your 2html, not to previously patched version.
> Ответ на сообщение «Re: Progress indicator for :TOhtml command»,
> присланное в 10:59:42 06 июня 2010, Воскресенье,
> отправитель Benjamin Fritz:
> It is odd: the only problem in your script is redrawstatus which is called
> only 100 times (without styles, 109 with) (>21 seconds), while in my
> script redrawstatus called 328 times takes less than a second.
> Second problem with the whole 2html is buffer switching, I think you should
> consider instead of doing constant switches, save every line in a List and
> only after everything is finished create a new buffer and call setline(1,
> s:list). Note that new versions of my script are faster (but not much)
> then your 2html because I use this technique.
> And, why do you calculate length of the title at each progressbarupdate?
> Attached patch fixes this and the case when there is no space for progress
> Текст сообщения:
> > On Jun 5, 8:10 pm, ZyX <zyx....@...> wrote:
> > > It occures that the problem is not floating-point math: the attached
> > > patch removes this math but does not add any perfomance.
> > Yes, I did not expect any performance gains from removing the little
> > bit of remaining floating point, since it is just up to 100
> > calculations done once at the start and thereafter only when the
> > window changes size. It is a good idea to remove, because as you point
> > out, that amount of precision is probably unnecessary, and it would
> > just introduce another dependency.
> > > It also removes recalculating
> > > progress bar width (you just used used some generic progress bar?) and
> > > needs_redraw.
> > Yes, we did use a generic progress bar as the starting point for this.
> > However, I think it IS necessary to recalculate the progress bar
> > width. This is done so that if the user changes window sizes, the
> > progress bar will be updated accordingly. We don't want a progress bar
> > that is too big to fit in the window, or smaller than needed for
> > decent viewing. With your patch, if you start with the gvim window
> > maximized, then restore the window to a smaller size, Vim goes blank
> > until the next progress bar update, and then the progress bar is too
> > large to fit on the screen and is truncated. This is not desirable,
> > but perhaps it would acceptable if the performance gains are great
> > enough. This does not seem to be the case, because I added back in the
> > size recalculation with no noticeable performance hit.
> > The needs_redraw was done in order to allow us to call redrawstatus on
> > the correct window. :help redrawstatus says that it redraws the status
> > line for the *current window* only unless you use redrawstatus! which
> > redraws all windows. In practice, however, it does not seem to matter
> > which window we use it in. Why is this?
> > > Also, why you forbid profiling progress bar functions? It is also
> > > fixed.
> > Good catch, that's certainly something to include going forward.
> > There is a slight speed gain from your patch, however there is a
> > mistaken assumption in the way you update the progress bar. Your code
> > assumes that the progress bar will only ever update by one tick at a
> > time. Updating the progress bar without your patch calculates the
> > entire string every time, using repeat(). Your update simply adds one
> > to the colored string of spaces, and subtracts one from the uncolored.
> > This does not work if the user folds away some text and does not use
> > dynamic folding, it does not work when there are fewer than 100 lines
> > in the text to convert, and it does not work for the second use of the
> > progress bar, where there are usually fewer that 100 highlight groups
> > to process.
> > I corrected this problem and initially, the performance still seemed
> > to be improved over the previous version. However, I noticed afterward
> > that part of the patch removes the "sleep 100m" from the "processing
> > classes" step. I took this line out of the original script for a fair
> > comparison, and got the following timings, converting
> > autoload/netrw.vim (7764 lines) with dynamic folding enabled:
> > Before patch: 50 seconds
> > Patch from ZyX: 49 seconds
> > Fixed patch: 51 seconds
> > So, it looks like the patch is actually no faster, and potentially
> > slightly slower than the precalculated version.
> > I have therefore attached an updated version of my last submission,
> > which removes floating point from the calculate_ticks function, and
> > incorporates some of the other improvements from ZyX.
> > This version takes 50 seconds to convert netrw, if I comment out the
> > sleep 100 line. Do we want this line in the code? Without it, if there
> > are not very many highlight groups to process, the "processing
> > classes" bar flashes by without being seen. This happens anyway for
> > very small selections. I don't know how I feel about deliberately
> > slowing down the execution. I have left it commented out for now.
> > I am very curious about this:
> > " Note that you must use len(split) instead of len() if you want to use
> > " unicode in title
> > let self.pb_len = max_len-len(split(self.title, '\zs'))-3-4-2
> > Can someone explain the problem described in the comment a little
> > better? And why does the split on '\zs' work to fix the problem?
- << Previous post in topic Next post in topic >>