EBUSCore 1.2.X slow to set all players EBU Details

We use Stratification but not handicaps so part of the pre event setup is to download the latest EBU database (and member database from Bridgewebs) and then set all players EBU details. This whistles through in a couple of seconds on 1.1.X. On 1.2.1 and 1.2.2 (beta) it takes 3-4 minutes, I suspect because it is calculating handicaps even though the box Handicaps by Grade is unchecked. Is my suspicion correct and can I turn off calculating Handicaps?

Comments

  • Filling NGS grade (for stratification by grade or handicap by NGS) involves going through the public NGS web interface - what takes particular time is waiting for the request to timeout for players whose NGS is private.

    But you are right to say that if NGS is not needed the process should not be slow.

  • I updated the main EBU members.dat file yesterday, deliberately ticking stratification by grade and it took (actual) hours - as expected.

    I repeated this today (on a copy) without out stratification/handicap by grade and it is again taking hours with 1.2.1 - rather than the minutes that it took with 1.1.x. So I think I can confirm that there is a change in behaviour.

  • Thanks - I will investigate.

  • Jonathan et al....
    Michael Clark can probably elucidate further but 1.2.x uses API version 3 whereas 1.1.x used API version 2. In version 3, there is an authoristaion process on each access which may well be slowing it down. A lot depends also on the size of the database, but I never found a way of accessing the whole of the data in one call, so you necessarily have about 1/4 sec delay for evvery ReadGrade access. Its not too bad if its a club access, since the information 'for that club' can be read in one go (albeit still takes a while), but otherwise eg for the EBU memebrs file, it will take ages even if it is interactive. i am not clear if there is currently any way to speed this up, but the ReadGrade call is fundamental to the usage of the function so whether you have Handicaps ticked or not will makle little difference to the elapsed time.

  • The two APIs behave identically in this respect, so there shouldn't be any difference. Takes around 0.6 to 0.8 seconds to retrieve a record, so for most fields this should be done in a minute or so.

    And it doesn't time out when it hits a private record - it tells you that just as quickly as it tells you a grade for a public one. So if that's taking much longer then something else is going on in EBUScore.

  • Does it need the API for information other than NGS? The old version just used the downloaded EBU database.

  • Ah yes - thats right, Robin! The NGS is only needed for Handicap or Stratify by NGS purposes. I thought that might be the main purpose of thebutton, but I guess you can omit that, so the Details would really be just about matching names to ebu numbers and some info on their County and MP Grade - essentially the information which is held in the downloaded database. Actually, if the downloaded database included Grades, then the button would work very quickly...

  • The grades can go up and down and the grades in the database will not be current, while the master point rank in the database will usually be sufficiently up to date.

  • Since the Active Members download file is updated regularly (daily ?), it ought to be reasonably current. And even if a little "stale", NGS grades don't shift violently overnight (as a rule). So my vote would be to add NGS Grade (but not percentage) to the Active Members download that scoring programs pull, and then they can use it or not (EBUScore could even be made clever enough to let the user decide which source to use - the download or the API).

Sign In or Register to comment.