[urbit] Any advice for speeding up the Hoon edit/run cycle

[Burton Samograd]

Hi,

I've been working on the 99 Lisp problems in Hoon and it's been fun, but
the guru meditation sessions between the edits of my code and being able to
run (about 60 seconds/edit) are testing even my excessive patience (which
has never been known to be excessive).

Is there any advice on how to speed this up? Right now I'm editing
directly in my %home desk sync'ed to a unix mount point (which I think is
the only way to do editing). Would it maybe be faster if I created an
empty desk, mounted that and edited from there? I ask because I'm no so
sure how to create an empty desk yet, so if something like that would work,
please post the commands to do that for posterity.

Any other advice on how to speed the development cycle up other than
pulling up my sleeves, digging into the event handling code and trying to
speed it up (which I would like to get to eventually, but I'm hooked on
learning Hoon/Nock at the moment).

Thanks.

Burton

[Curtis Yarvin]

Wow, that's crazy. It's too slow for me as well, but it's nowhere near
that slow - only a few seconds. (Obviously by rights it should be
instantaneous - worse, it's been instantaneous in old versions of the
system.) What hardware/software are you on?

I thought Philip recently fixed a performance bug in this cycle where all
of %clay was getting rehashed on every change. There may (must) be more
low-hanging fruit in this area. It's a relatively good area for a limited
modified performance jihad.

(Our general approach to optimization is that we're as lazy about it as
possible, but no lazier. In particular, the time not to be lazy about
optimization is when it actually impedes development.)

At least in theory, there's no real point in creating an empty desk, for a
couple of reasons. First, you're not actually copying any data, because
revision control. Second, since %clay is a typed filesystem, every file is
interpreted as a case of its mark, and marks don't just float down from
heaven; they are defined by the source path *in the same desk (branch) and
case (version)*. So your empty desk will actually be dysfunctional.

Post by Burton Samograd
Hi,
I've been working on the 99 Lisp problems in Hoon and it's been fun, but
the guru meditation sessions between the edits of my code and being able to
run (about 60 seconds/edit) are testing even my excessive patience (which
has never been known to be excessive).
Is there any advice on how to speed this up? Right now I'm editing
directly in my %home desk sync'ed to a unix mount point (which I think is
the only way to do editing). Would it maybe be faster if I created an
empty desk, mounted that and edited from there? I ask because I'm no so
sure how to create an empty desk yet, so if something like that would work,
please post the commands to do that for posterity.
Any other advice on how to speed the development cycle up other than
pulling up my sleeves, digging into the event handling code and trying to
speed it up (which I would like to get to eventually, but I'm hooked on
learning Hoon/Nock at the moment).
Thanks.
Burton
--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[Philip Monk]

So, I think I've found the issue here, and Anton and I have come up with a
workaround. Firstly, several hundred revisions of a random markdown file
caused no slowdown. Secondly, a hundred revisions of adding comments to
ape/talk.hoon caused no slowdown. Thirdly, a hundred revisions of adding
"." lines to the end of ape/talk.hoon caused no slowdown.

I did reproduce the problem by adding a "." to the end of
pub/talk/fab/hymn.hook while having talk open. What we believe is that
every time we autoreload talk, we generate a new request to urb.js, which
causes eyre to ask ford to ask clay to watch all of its dependencies. All
fine and good. When an update happens again, the dependencies for talk
have changed, so we autoreload, and eyre tells ford to tell clay to not
listen for more updates on the old set of dependencies. It then says to
listen for updates on the new set of dependencies and sends the new page to
the browser. The browser asks again for urb.js, but this is for urb.js on
the newest revision, which may have a different dependency set. Thus, the
old urb.js request's dependencies are never canceled, which means that clay
has to continually check if they change. What should happen, but doesn't,
is that whenever an http request is canceled, we cancel its
subscriptions. The workaround is to somehow kick urb.js's dependencies.

tl;dr is that eyre doesn't properly dispose of dead connections, as
described in https://github.com/urbit/urbit/issues/368 . The temporary
workaround is to make a trivial change to a mark whenever things get
annoyingly slow. This can be just `echo "::" >> pier/home/mar/atom.hoon`.

Thanks for the bug report, and please let us know if this restores ~matfeb
to full speed.

Post by Curtis Yarvin
Wow, that's crazy. It's too slow for me as well, but it's nowhere near
that slow - only a few seconds. (Obviously by rights it should be
instantaneous - worse, it's been instantaneous in old versions of the
system.) What hardware/software are you on?
I thought Philip recently fixed a performance bug in this cycle where all
of %clay was getting rehashed on every change. There may (must) be more
low-hanging fruit in this area. It's a relatively good area for a limited
modified performance jihad.
(Our general approach to optimization is that we're as lazy about it as
possible, but no lazier. In particular, the time not to be lazy about
optimization is when it actually impedes development.)
At least in theory, there's no real point in creating an empty desk, for a
couple of reasons. First, you're not actually copying any data, because
revision control. Second, since %clay is a typed filesystem, every file is
interpreted as a case of its mark, and marks don't just float down from
heaven; they are defined by the source path *in the same desk (branch) and
case (version)*. So your empty desk will actually be dysfunctional.

Post by Burton Samograd
Hi,
I've been working on the 99 Lisp problems in Hoon and it's been fun, but
the guru meditation sessions between the edits of my code and being able to
run (about 60 seconds/edit) are testing even my excessive patience (which
has never been known to be excessive).
Is there any advice on how to speed this up? Right now I'm editing
directly in my %home desk sync'ed to a unix mount point (which I think is
the only way to do editing). Would it maybe be faster if I created an
empty desk, mounted that and edited from there? I ask because I'm no so
sure how to create an empty desk yet, so if something like that would work,
please post the commands to do that for posterity.
Any other advice on how to speed the development cycle up other than
pulling up my sleeves, digging into the event handling code and trying to
speed it up (which I would like to get to eventually, but I'm hooked on
learning Hoon/Nock at the moment).
Thanks.
Burton
--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.