unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Luciana Lima Brito <lubrito@posteo.net>
To: Christopher Baines <mail@cbaines.net>, guix-devel@gnu.org
Subject: Re: Outreachy: Timeline tasks
Date: Fri, 30 Apr 2021 15:44:43 +0000	[thread overview]
Message-ID: <20210430124443.561fb340@lubrito> (raw)
In-Reply-To: <87mttgetm5.fsf@cbaines.net>

Hi,

On Thu, 29 Apr 2021 21:14:10 +0100
Christopher Baines <mail@cbaines.net> wrote:

> Great, can you add more detail to this bit? Given the instrumentation
> is a really important part, it would be good to have some working
> ideas for what this chart might look like, and what goes in to making
> it (like where the data comes from and if and where it's stored).

Task 1: Add instrumentation to identify the slow parts of processing
new revisions:

  - Implementing a chart over time to identify slow parts:
	- The chart should consider two aspects, the time took by
	  each specific part, and its name, for identification purpose.
	  A bar chart is a good candidate for this task, it is simple
	  and can show the whole picture of the time taken by the
	  system to process a new revision;
	- The bars on the chart should be sorted in order of precedence
	  of the process in the X axis, and its height, which is
	  determined by the time it takes, measured in the Y
	  axis;
	- The charts should work as picture-logs for timing;
	- A chart should be generated for each new revision in real
	  time;
	- The time is already being computed for each part and it is
	  shown in the logs, the same data can be used to build the
	  charts. This way data does not need to be stored, because the
	  chart can be built in real time, but the chart itself needs
	  to be stored, in the same way as the logs already are.

> I'd try to set out more of a strategy, so what might be causes of
> slowness, how would you investigate them, and what are common
> approaches to making those things faster?

Task 2: Improve the performance of these slow parts:

  - Select candidate parts to be analyzed;
  - Identify the causes of slowness:
	- If it uses queries, perform query analysis, for example using
	  EXPLAIN and ANALYZE, get its statistics and improve them when
	  needed;
	- On the code, investigate the structure, for example, using
	  Tracing to discover if a recursion is too long and if it can
	  be modified to be tail recursive.
  - Implement the required improvements.

In fact, I have never performed improvements on queries or code this
way, but I am studying. Please, tell me if I am missing important
details. See what you think about that.

-- 
Best Regards,

Luciana Lima Brito
MSc. in Computer Science


  reply	other threads:[~2021-04-30 15:45 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-28 17:59 Outreachy: Timeline tasks Luciana Lima Brito
2021-04-28 18:17 ` Christopher Baines
2021-04-28 19:20   ` Luciana Lima Brito
2021-04-28 20:00     ` Christopher Baines
2021-04-29 16:02       ` lubrito
2021-04-29 20:14         ` Christopher Baines
2021-04-30 15:44           ` Luciana Lima Brito [this message]
2021-04-30 17:05             ` Christopher Baines
2021-04-30 21:19               ` Luciana Lima Brito
2021-05-01  8:16                 ` Christopher Baines
2021-05-01 13:48                   ` Luciana Lima Brito
2021-05-01 19:07                     ` Christopher Baines
2021-05-01 23:17                       ` Luciana Lima Brito
2021-05-02  9:20                         ` Christopher Baines
2021-05-03 14:23                           ` Luciana Lima Brito
2021-05-03 15:29                             ` Christopher Baines

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://guix.gnu.org/

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

  git send-email \
    --in-reply-to=20210430124443.561fb340@lubrito \
    --to=lubrito@posteo.net \
    --cc=guix-devel@gnu.org \
    --cc=mail@cbaines.net \
    /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.savannah.gnu.org/cgit/guix.git

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).