On 12/11/18 11:42 PM, Andrew Parsloe wrote:
>
> On 12/12/2018 12:34 PM, Richard Kimberly Heck wrote:
>> On 12/11/18 6:25 PM, Richard Kimberly Heck wrote:
>>> On 12/11/18 5:56 PM, Andrew Parsloe wrote:
>>>> The kpsewhich bug which caused slowness on windows when a document
>>>> used a bibtex database in the initial 2.3.1 installer, has reappeared
>>>> in 2.3.2 on my windows 7 system. See
>>>> https://marc.info/?l=lyx-devel&m=153580258026277&w=2. A second windows
>>>> 2.3.1 installer was produced in which the problem was fixed. It's a
>>>> sufficient irritant on 2.3.2 for me to revert to using 2.3.1.
>>> Patches were committed at 7c614cc6 and some following fixups (see bug
>>> #9158) that were supposed to fix this. I guess this is another example
>>> where we don't get enough testing on Windows. And another reason for me
>>> to figure out how to produce 'testing' binaries.
>>>
>>> Anyway, can you please try with 2.3.2 again and activate the "files"
>>> component of the messages pane? I think we are looking for messages
>>> about new bibfiles. Failing that, or additionally, if you can tell me
>>> exactly what to do to get the slowness, I can try on my virtual
>>> machine.
>> OK, I went read that old thread and did what I think revealed the
>> problem before. I ran LyX.exe with the --verbose flag, which had
>> previously shown repeated runs of kpsewhich. I did not see these on new
>> paragraphs, or deleted paragraphs, or anything, as Enrico had previously
>> reported. Moreover, on activating the Messages Pane as described above,
>> I just keep getting "bibfiles unchanged", which means the cache was
>> valid, which is what is supposed to happen.
>>
>> Can you please see if you're getting the same results or different ones?
>> It could be that the problem is coming from somewhere else now and it
>> just seems familiar.
>>
>> Riki
>
> Sorry for the delayed response. I've been away from the computer. Like
> you, I see no call to kpsewhich for a new paragraph. However, a *cut*
> operation, does trigger a kpsewhich call (a couple of lines are
> written to kpsewhich.log). The message pane (with "files" selected) shows
>
> 17:38:59.564: Cut (cut: Ctrl+X, Shift+Del)Buffer.cpp (4897): Bibfiles
> unchanged.
> BufferParams.cpp (321): Checking whether document is in a system
> dir... no
> Buffer.cpp (2435): Reading file location for maths
> Buffer.cpp (2442): Found at: D:/texmf/bibtex/bib/local/maths.bib
> Buffer.cpp (4897): Bibfiles unchanged.
> 17:39:04.774: PasteBuffer.cpp (4897): Bibfiles unchanged.
>
> I have a bibliography called "maths.bib".

OK, I see the issue. When you cut, something was happening that caused
the cache we created to be invalidated. As a result, it had to be
rebuilt in that case, and then you get the call to kpsewhich. I have a
patch that should fix this. I'll build a new binary for Windows as soon
as I can, maybe tomorrow if I can find the time. Otherwise it will be
Thursday.

I still am puzzled why kpsewhich is so slow on Windows, but that's a
different issue. I guess maybe it has to do with how these processes are
spawned. Anyway, since this doesn't seem to affect other platforms, I'll
probably go ahead and release for other platforms around the same time,
and the Windows one can be a few days late.

Riki


Reply via email to