Christian Ohler <[EMAIL PROTECTED]> writes:

> I could respond point by point, but the question boils down to: Why
> implement a polling-based approach when we have a notification
> mechanism (through process filter functions)?
>
> If we want to process larger chunks, we should use a conditional in
> the process filter function; e.g., only call the parser when more than
> X bytes of input have arrived.  This is a much more direct way to
> ensure that input is processed in chunks of the desired size.
> Sleeping for a while and hoping that a chunk of the right size will
> arrive in the meantime is much less reliable.
>
> Isn't a conditional in the process filter function a preferable
> solution?

Now that I've actually profiled both the original git-log function and
the new xgit-log function, I see that indeed waiting for git output is
not the big issue after all.  The issue is that xgit-log-parse takes a
long time in processing the output.

Here are the profiling results, based on a project with 1043 revisions.

git-log :: (caveat: I defaliased xgit-log-mode to dvc-log-buffer-mode)

Function Name                 Call Count  Elapsed Time  Average Time
============================  ==========  ============  ============
git-log                       1           0.118596      0.118596
ewoc-enter-last               1           0.000242      0.000242
dvc-log-buffer-mode           1           7.4e-05       7.4e-05

xgit-log ::

Function Name                 Call Count  Elapsed Time  Average Time
============================  ==========  ============  ============
xgit-log-parse                1           2.354476      2.354476
ewoc-enter-last               1043        0.7651790000  0.0007336327
xgit-log                      1           0.019899      0.019899
dvc-build-revision-list       1           0.0194069999  0.0194069999
dvc-revision-prev             1041        0.0159550000  1.532...e-05
make-dvc-revlist-entry-patch  1041        0.0075620000  7.264...e-06
make-xgit-revision-st         1041        0.0075170000  7.220...e-06
xgit-revision-st-hash         2082        0.0041789999  2.007...e-06

Basically, the difference is that git-log relies on xgit-log-mode to do
font-locking, without doing any processing of the results itself.

So I now agree that we should be using filter-function and just doing
parsing after a certain number of lines/bytes/whatever are processed.
Then when the process finishes, have the process sentinel call the
parser function once more to take care of the scraps.

I was a bit worried about how much the parser would affect
responsiveness and cursor movement, but I'm now reasonably confident
that it should work out.

-- 
       Michael Olson -- FSF Associate Member #652     |
 http://mwolson.org/ -- Jabber: mwolson_at_hcoop.net  |  /` |\ | | |
            Sysadmin -- Hobbies: Lisp, GP2X, HCoop    | |_] | \| |_|
Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner |

Attachment: pgpgHa961d1im.pgp
Description: PGP signature

_______________________________________________
Dvc-dev mailing list
[email protected]
https://mail.gna.org/listinfo/dvc-dev

Reply via email to