discussion and development of piem
 help / color / mirror / code / Atom feed
From: Xinglu Chen <public@yoctocell.xyz>
To: Kyle Meyer <kyle@kyleam.com>
Cc: piem@inbox.kyleam.com
Subject: Re: Thoughts and feedback on piem-lei
Date: Thu, 17 Jun 2021 10:52:28 +0200	[thread overview]
Message-ID: <87pmwk7u0j.fsf@yoctocell.xyz> (raw)
In-Reply-To: <87r1h3lps0.fsf@kyleam.com>

[-- Attachment #1: Type: text/plain, Size: 2113 bytes --]

On Tue, Jun 15 2021, Kyle Meyer wrote:

> Xinglu Chen writes:
>
>> Hi,
>>
>> I played around with the lei interface for a bit, and I have some
>> thoughts and observations:
>
> Thanks a lot for writing this up.

You are welcome!

>> * I noticed that ‘piem-lei-query’ was a little slow, at least compared
>>   to notmuch.el.  I have indexed the guix-devel and guix-patches mailing
>>   lists (I think) and making the query ‘d:20.days.ago.. guix’ took
>>   around three seconds.  It seems like it waits for all the results from
>>   lei to arrive before processing them, whereas notmuch.el processes the
>>   messages as they come, similar to ‘git log’.
>
> Right, piem-lei-query waits for the entire output.  Moving to an
> asynchronous process is definitely a direction I'd like to go.  Offhand
> I think lei-q's ldjson format should be amenable, but I haven't started
> looking into it yet.
>
> Also, I'd be curious how much of a speedup you see on the second run.
> From the command line, I've noticed it sometimes takes lei-q a bit of
> time before outputting anything at all, and that it's much faster on the
> second run of the query.  If that's the main source of the slowdown,
> async processing on piem's end of course won't help.

Hmm, it does seem to get a bit faster on the second run, thanks for
pointing this out.

>> * In PGP singed messages there is a ‘lei blob OID’ attachment, not sure
>>   why that is there
> [...]
>>   [-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 5599 bytes --]
>>   [-- lei blob 69667b191433ea4c4a46dd8414a4c5ee366d8e4d:1 --]
>
> That's what `lei q --format=text ...' outputs.  The plan is to
> eventually process the raw buffer (e.g., mm-dissect-buffer), but
> --format=text was an easy way to get things off the ground.

Ah, OK, you can probably tell that I haven’t used lei that much :)

> Thanks again for the feedback.  My free time is a bit crunched at the
> moment, but some of these should be next-ish steps when I get back to
> working on piem-lei.

No worries, no need to hurry :)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 861 bytes --]

      reply	other threads:[~2021-06-17  8:52 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-12 20:02 Thoughts and feedback on piem-lei Xinglu Chen
2021-06-15  4:23 ` Kyle Meyer
2021-06-17  8:52   ` Xinglu Chen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://git.kyleam.com/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87pmwk7u0j.fsf@yoctocell.xyz \
    --to=public@yoctocell.xyz \
    --cc=kyle@kyleam.com \
    --cc=piem@inbox.kyleam.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.kyleam.com/piem/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).