Generate SAN performance issue about bishop

[alexobviously]

Getting the SAN form of a move is expensive because it needs to check if the king is attacked and other game end conditions, since the SAN string has a check/checkmate indicator ('+' / '#').

4 seconds for that operation does seem very long though - I just wrote a test script and it takes around 200ms for me to parse and build a game with 80 moves. If you switch to the development branch you can try it, or take a look at this commit. Also feel free to share your code and I'll see if there's anything obvious in it that's slowing it down.

Having said that, I am not happy with the way that 'checks' are computed in Bishop and changing that is one of my current tasks. It's the single slowest thing in the library. My goal is to (very soon) make it possible to compute checks/attacks from a state alone in a more efficient way, and also probably to store the checks in the state itself. This will make the whole SAN thing much more efficient (and also allow me to add things like actions that depend on checks).

Another thing is that I am soon (likely tomorrow), going to release 1.2.3 with a GameNavigator class that handles all of this stuff for you :)

[wwawrzy]

Thank you for the quick response. Actually, when I checked the time for more accurate results, I ran the test multiple times. Currently, it gives me around 400 ms, which is within the margin of error for CPU speed, etc.

I have a PGN loaded as a tree on my end (with possible branches, comments, etc.). The edges represent SAN moves, and the vertices represent positions in FEN. I fill the entire tree (vertices) with FEN values so that I can quickly navigate through it if necessary.

Also, I'm trying to connect the analysis of specific positions to a separate server with an SF engine that will evaluate the current position, which could be useful in analysis and possible caching so that the first moves in the opening don't need to be counted repeatedly.

I'm a little worried about performance since changing the library speeds up the process so significantly.

Thank you for preparing the Navigator. In about a week, I'll try to work more with the bishop library code and prepare a possible comparison, and maybe I'll be able to trace specific places in the code that may be causing delays.

[alexobviously]

I think if you're getting significant delays, it's likely you're re-computing states that really only need to be computed once, but yeah the navigator will fix that. I'd say that 400ms is workable, since you're probably not doing a ton of these simultaneously right? But anyway regardless, the efficiency of this will get much better when I change the attacks thing. Don't know exactly when it'll be because it's complex, but probably within the next month. Navigator will be in some time today - the core of it works, I just need to make some decisions on the API.

Also worth noting that looking algebraic moves up (e.g. b1c3) is much cheaper than SAN. Obviously you can't do this when importing the PGN since it contains SAN moves, but if you want to look up states you've already computed by move or something, then algebraic is going to be better. (again though you probably don't have to worry about this with the navigator).

[alexobviously]

1.2.3 is out with an early version of GameNavigator, and built in PGN parsing. This is a minimal version of the navigator, and it's missing a few features. The PGN parsing function doesn't understand branches yet, and branching isn't in its final form in the navigator either. But yeah, have a look and give me your thoughts - see example/viewer.dart.

[alexobviously]

@wwawrzy I have added an optimisation in 1.2.5 that should help you out here - parsing my 80 move test PGN now takes <100ms

Basically the optimisation is that calculating attacks/checks on SAN generation is now optional, and isn't used in cases where we just want to compare an existing move with possible SAN strings (we just strip the '#' and '+' out and compare them with a simpler version). More optimisations regarding calculations of checks are coming but I think this should do for now.

This should require no changes to your code :)

[alexobviously]

I'm closing this as the performance is now reasonably good