Skip to content

Resolving dependencies takes too long #1524

Closed
Closed
Resolving dependencies takes too long#1524
Labels
bug

Description

@Stift
Stift
opened on Mar 17, 2016

We have around 90+ direct dependencies and like ~200 dependencies in total in our project and since v2.52.9 the resolving takes 'forever'. It seems for me, that the fix of #1520 has caused that problem. Before an paket install took like 7-10s and now we are waiting +15min at least (I had to stop this and did not measure the correct timing).

Activity

  1. forki commented on Mar 17, 2016

    @forki
    forki
    on Mar 17, 2016
    Member

    yeah looks like a massive perf issue. I will investigate
    /cc @isaacabraham

  2. forki
    added
    bug
    on Mar 17, 2016

  3. forki commented on Mar 17, 2016

    @forki
    forki
    on Mar 17, 2016
    Member

    I just reverted that change. Can just please check if perf is restored? Seems I need to investigate deeper

  4. forki commented on Mar 17, 2016

    @forki
    forki
    on Mar 17, 2016
    Member

    pushed 2.52.12 - I think I verschlimmbessert it in 2.52.11

  5. Stift commented on Mar 17, 2016

    @Stift
    Stift
    on Mar 17, 2016
    ContributorAuthor

    Tested it with 2.52.12. and it's back to normal. Thx.

  6. forki commented on Mar 17, 2016

    @forki
    forki
    on Mar 17, 2016
    Member

    OK now I need to find a proper fix for #1520
    @Stift I guess I need to push another version soon and ask you again if perf is still good ;-)

  7. Stift commented on Mar 17, 2016

    @Stift
    Stift
    on Mar 17, 2016
    ContributorAuthor

    Just do so. I'm glad to test it.
    But today is St. Patricks Day and I'm off and out in a few hours:

  8. forki commented on Mar 17, 2016

    @forki
    forki
    on Mar 17, 2016
    Member

    2.52.13 will be online in 2min. Please give it a try

  9. Stift commented on Mar 17, 2016

    @Stift
    Stift
    on Mar 17, 2016
    ContributorAuthor

    that will fit

  10. forki
    added a commit that references this issue on Mar 17, 2016

    Restore resolver performance - clsoes #1524

    1948e59

  11. forki commented on Mar 17, 2016

    @forki
    forki
    on Mar 17, 2016
    Member

    so it's online

  12. Stift commented on Mar 17, 2016

    @Stift
    Stift
    on Mar 17, 2016
    ContributorAuthor

    I'm already testing it. I get some warnings that I cannot specifcally say what they are about:

    Could not resolve package Npgsql:
 - Dependencies file requested: 2.2.5-custom
 - <customPackage1> 1.0.11044 requested: >= 0
 - <customPackage2> 1.0.11149 requested: >= 2.2.5
 - <customPackage3> 1.1.10087 requested: >= 2.0.0 < 3.0.0

    Also some of the numbers do not fit to the package itself. Is something mixing up here?

  13. forki commented on Mar 17, 2016

    @forki
    forki
    on Mar 17, 2016
    Member

    shit. soo I'm not done

  14. Stift commented on Mar 17, 2016

    @Stift
    Stift
    on Mar 17, 2016
    ContributorAuthor

    Also after a second run of install downloads now all packages again and this again takes a while.
    First run: 26s
    Second run (downloading?): +5min

  15. Stift commented on Mar 17, 2016

    @Stift
    Stift
    on Mar 17, 2016
    ContributorAuthor

    sorry for that

  16. 16 remaining items

  17. forki commented on Mar 18, 2016

    @forki
    forki
    on Mar 18, 2016
    Member

    Yes everything that improves error messages is good.
    On Mar 18, 2016 18:03, "Christian Fiebrig" notifications@github.com wrote:

    Yes. I misunderstood the message! Sorry for that confusion.

    If I read the message like this, I would maybe understand this earlier.
    Could not resolve package Npgsql:

    • Dependencies file requested package Npgsql: 2.2.5-custom
    • 1.0.11044 requested package Npgsql: >= 0
    • 1.0.11149 requested package Npgsql: >= 2.2.5
    • 1.1.10087 requested package Npgsql: >= 2.0.0 < 3.0.0

    Should I make a pr for this?

    —
    You are receiving this because you were mentioned.
    Reply to this email directly or view it on GitHub
    #1524 (comment)

  18. forki
    closed this as completedon Mar 19, 2016
  19. forki
    added a commit that references this issue on Mar 22, 2016

    Fix resolver bug spotted by property based testing - #1524

    6e0de9c

  20. forki commented on Mar 22, 2016

    @forki
    forki
    on Mar 22, 2016
    Member

    @Stift seems that I need your help again. Property based testing revealed another issue around that code. I was able to fix that but I want to know if how bad the perf is. Can you please check 3.0.0-alpha079? Thanks mate

  21. forki
    added a commit that references this issue on Mar 22, 2016

    Fix resolver bug spotted by property based testing - #1524

    807c9eb

  22. Stift commented on Mar 22, 2016

    @Stift
    Stift
    on Mar 22, 2016
    ContributorAuthor

    No problem.
    stats for paket install

    Commit v2.54.0 v3.0.0-alpha079
    Unclean (with error in nupkg) 24s 2h+
    Clean (paket.lock is fine) 8s 8s
    Clean (paket.lock has to be updated) 11s 13s

    and for a paket update nuget package only on a clean commit

    v2.54.0 v3.0.0-alpha079
    161s 161s

    The unclean commit was the one that originally made problems and where we had a package which was not configured well.

    I mean the only issue that I see is that with this unclean package we get into a situation where paket does not behave that well. When I looked in the verbose output of 2.52.10 (where the original problem started) I had the feeling paket was running in circles.

  23. forki commented on Mar 22, 2016

    @forki
    forki
    on Mar 22, 2016
    Member

    So apart from a strange state it was ok?

  24. Stift commented on Mar 22, 2016

    @Stift
    Stift
    on Mar 22, 2016
    ContributorAuthor

    yes. Seems like current stable and alpha are similiar.

  25. Stift commented on Mar 22, 2016

    @Stift
    Stift
    on Mar 22, 2016
    ContributorAuthor

    I just fear a bad user experience when paket cannot detect that it runs in a regression.

  26. forki commented on Mar 22, 2016

    @forki
    forki
    on Mar 22, 2016
    Member

    Yes we need to find that error. Question is how to reproduce on my machine.
    On Mar 22, 2016 8:56 PM, "Christian Fiebrig" notifications@github.com
    wrote:

    I just fear a bad user experience when paket cannot detect that it runs in
    a regression.

    —
    You are receiving this because you modified the open/close state.
    Reply to this email directly or view it on GitHub
    #1524 (comment)

  27. forki
    added a commit that references this issue on Mar 23, 2016

    Fix resolver bug spotted by property based testing - #1524

    619db4c

  28. forki commented on Mar 23, 2016

    @forki
    forki
    on Mar 23, 2016
    Member

    ok I added another 3.0alpha package. I hope it solves that 2h hour thing

  29. Stift commented on Mar 23, 2016

    @Stift
    Stift
    on Mar 23, 2016
    ContributorAuthor

    I tested with 3.0.0-alpha80 and with the unclean package paket install takes about 27 seconds. On a clean repo without the failing package we still have around 15 seconds. For me this looks definetely better and acceptable (from a user perspective).

    Update is also fine on the clean one.

  30. forki commented on Mar 23, 2016

    @forki
    forki
    on Mar 23, 2016
    Member

    thanks buddy.

  31. Stift commented on Mar 23, 2016

    @Stift
    Stift
    on Mar 23, 2016
    ContributorAuthor

    no problem. Glad to serve and give something back.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bug

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions