Fulvio wrote:
> Very interesting, i didn't suppose that the engine can output so many info
> that
>
> scid get stucked simply parsing it.
> However "update idletasks" don't solve the problem.
> The point is that fileevents have higher priority than idletasks, so "update
> idletasks" refresh the GUI (not new user events) but fileevents are still
> there to be processed.
> I suppose that processAnalysisInput can be optimized in many ways (for
> example
>
> "string range" should be faster than "split" and "lindex").
These tune-ups don't make much difference
> I think we need a way to discard old info.
> If in the buffer there are many:
> info depth 11 ....
> info depth 12 ....
> info depth 13 ....
> we should discard info with lower depth and process only the last one.
> Do you have other ideas?
This is probably what i'm thinking about.
It stops processing engine lines after depth at which mate is detected (plus
delta)
(Patch applies to clean SCID-4.3)
Is this idea ok ? I'm not processing the last one though.. but the first few.
Perhaps this
> set ::analysis(maxDepth$n) $mate
should be
> set ::analysis(maxDepth$n) $plies
but it seems to run better as is.
Steven
sa_dont_process_extra_depths.patch
Description: Binary data
------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________ Scid-users mailing list Scid-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scid-users
