Re: Outreachy: Timeline tasks

[Christopher Baines <mail@cbaines.net>]

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


Luciana Lima Brito <lubrito@posteo.net> writes:

> 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;

I'm not sure what you mean by "precedence of the process" here?

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

It would be good to say explicitly how the chart will be stored, since
"the same way as the logs already are" is quite vague.

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

Great, this is more like it.

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