Il 08/11/2011 21:37, Abdelrazak Younes ha scritto:
On 07/11/2011 10:22, Tommaso Cucinotta wrote:
Hi,
I just "enjoyed" extending the Find Advanced feature to exploit
multi-cores.
What about enjoying to implement the correct solution for the advanced
find feature? I'm sure you'll much more fun :-P
That may be proposed for the next year GSoC :-), if there's any student
willing to have that kind of fun :-)
From a preliminary/rough test, finding "The above bib" in UserGuide.lyx
(matching on the very last sentence of the document), takes
-) 15 secs with the current trunk
-) 8 secs with this patch applied
I am ready to bet that it will be even quicker with a single thread if
you implement the feature correctly... and by that I mean searching
the binary structure.
That's for sure, but rather than saying "correct" implementation, let's
say "efficient". The current one is inefficient, in that it relies
exclusively on the plain-text and latex export capability, for the
implementation, then we have a lot of text processing. The current
implementation has also the advantage that it required small
modifications to the "model" part of LyX (the GUI was far more invasive
for the multiple WorkAreas). Still, I can remember the first times I
committed that patch, having as feedback that it was too large and
invasive, and that it should have been more "incremental" :-).
I agree that matching directly the two graphs would be far faster, we
said that many times. Even though, the regular expression matching
should be re-interpreted someway.... However, who's willing to change
something that now kind of works to rewrite it from scratch :-) ? See my
comment above.
Perhaps that will happen for LyX 3.0 :-)! (do we have an enhancement
request in the Trac for this ?)
Too complicated for my taste :-)
What do you mean by "complicated", here ? Parallel is always more
complicated than sequential. Still, we can't keep living in the
sequential world, I guess you know.
Let's put it this way: this parallel patch is a small, incremental
modification to the code base that speeds up searching on most nowadays
PCs. Compare with rewriting the search capability from scratch, that
would require a huge invasive patch modifying probably each and every
inset.... that deserves the "complicated" adjective, IMHO :-) [but,
again, I agree that it would also reduce the search time by one or two
orders of magnitude].
Bye,
T.
