Loading ...
Sorry, an error occurred while loading the content.

57225Re: Progress indicator for :TOhtml command

Expand Messages
  • ZyX
    Jun 5, 2010
    • 0 Attachment
      Ответ на сообщение «Re: Progress indicator for :TOhtml command»,
      присланное в 19:39:15 05 июня 2010, Суббота,
      отправитель Benjamin Fritz:

      It occures that the problem is not floating-point math: the attached patch
      removes this math but does not add any perfomance. It also removes recalculating
      progress bar width (you just used used some generic progress bar?) and
      needs_redraw. Also, why you forbid profiling progress bar functions? It is also
      fixed.

      Текст сообщения:
      > On Thu, Jun 3, 2010 at 10:03 PM, Benjamin Fritz <fritzophrenic@...>
      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?
      >
    • Show all 28 messages in this topic