Bug 1925039 Comment 0 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

I'm trying to land [D224712](https://lando.services.mozilla.com/D224712/). It's the 16th patch in a stack of 39 patches. The stack consists of several bugs that are linked because they depend on each other. Just loading the page takes ~45 seconds. Trying to land it times out after 60 seconds.

If I remove the link to its child commit [D224713](https://lando.services.mozilla.com/D224713/) such that the stack only contains 16 patches, loading the page takes 20 seconds.

Let's do the math: 45/39 = 1.15s per patch. 16/20 = 0.8s per patch.

In phabricator I used its Conduit API pages to test the queries lando does to phabricator when loading D224712. They were fast.

Whatever else lando is doing has terrible performance characteristics and is to at the very least some extent __entirely unnecessary__. When I open [D224712](https://lando.services.mozilla.com/D224712/) in lando I am entirely uninterested in landing, or checking the status of, its children. They are for later.

Landing [D224712](https://lando.services.mozilla.com/D224712/) without children in the stack now takes ~40 seconds and leads to
>  Landing Failed
    The warnings present when the request was constructed have changed. Please acknowledge the new warnings and try again.

Acknowledging the warnings and landing again renders the same timing and result.

I have put the stack back together.
I'm trying to land [D224712](https://lando.services.mozilla.com/D224712/). It's the 16th patch in a stack of 39 patches. The stack consists of several bugs that are linked because they depend on each other. Just loading the page takes ~45 seconds. Trying to land it times out after 60 seconds.

If I remove the link to its child commit [D224713](https://lando.services.mozilla.com/D224713/) such that the stack only contains 16 patches, loading the page takes 20 seconds.

Let's do the math: 45/39 = 1.15s per patch. 20/16 = 1.25s per patch.

In phabricator I used its Conduit API pages to test the queries lando does to phabricator when loading D224712. They were fast.

Whatever else lando is doing has terrible performance characteristics and is to at the very least some extent __entirely unnecessary__. When I open [D224712](https://lando.services.mozilla.com/D224712/) in lando I am entirely uninterested in landing, or checking the status of, its children. They are for later.

Landing [D224712](https://lando.services.mozilla.com/D224712/) without children in the stack now takes ~40 seconds and leads to
>  Landing Failed
    The warnings present when the request was constructed have changed. Please acknowledge the new warnings and try again.

Acknowledging the warnings and landing again renders the same timing and result.

I have put the stack back together.
I'm trying to land [D224712](https://lando.services.mozilla.com/D224712/). It's the 16th patch in a stack of 39 patches. The stack consists of several bugs that are linked because they depend on each other. Just loading the page takes ~45 seconds. Trying to land it times out after 60 seconds.

If I remove the link to its child commit [D224713](https://lando.services.mozilla.com/D224713/) such that the stack only contains 16 patches, loading the page takes 20 seconds.

Let's do the math: 45/39 = 1.15s per patch. 20/16 = 1.25s per patch. Performance seems to scale almost linearly with the number of patches in the stack, regardless of whether they are parents or children of the one lando might need to land.

In phabricator I used its Conduit API pages to test the queries lando does to phabricator when loading D224712. They were fast.

Whatever else lando is doing has terrible performance characteristics and is to at the very least some extent __entirely unnecessary__. When I open [D224712](https://lando.services.mozilla.com/D224712/) in lando I am entirely uninterested in landing, or checking the status of, its children. They are for later.

Landing [D224712](https://lando.services.mozilla.com/D224712/) without children in the stack now takes ~40 seconds and leads to
>  Landing Failed
    The warnings present when the request was constructed have changed. Please acknowledge the new warnings and try again.

Acknowledging the warnings and landing again renders the same timing and result.

I have put the stack back together.

Back to Bug 1925039 Comment 0