#1620 Yap keeps reading after rendering

closed
Yap (316)
2012-11-08
2007-09-24
Hector C
No

Steps to reproduce: Open a dvi file in Yap and wait for the file to be completely rendered. Open File Monitor (from www.sysinternals.com) and set the filter to Yap. Wait 10 seconds, count the number of times Yap opened the file.

My results were between 400 and 7500 times per second! It doesn't matter whether you change pages or leave the file alone in the background. The only way the count would go down to about 10 times per second is to minimize the window.

I expect that Yap would stop trying to read the file in the disk after it finished rendering.

Could anybody post their measurements here for comparison?

In the attached screenshot, the cycle of opening the dvi file, reading info (not data), and closing the file is shown. My guess is that Yap wants to be sure that it has the latest version of the dvi file.

Regards,

++Hector C.

Discussion

  • Hector C

    Hector C - 2007-09-24

    Open file, get access, read info (not data), close file cicle.

     
  • Christian Schenk

    Logged In: YES
    user_id=67066
    Originator: NO

    Nice analysis. But where is the problem description?

     
  • Hector C

    Hector C - 2007-09-24

    Logged In: YES
    user_id=1414685
    Originator: YES

    The problem is that it tries to open the file up to 7500 times per second. This is the root of some "locking" problems reported before (both here and at WinEdt mail list). Yap does not leave a lock on the file, it is just accessing it so many times that it cannot be opened reliably by other programs.

    Besides minimizing (to the taskbar), there is another way to lower the number of openings: disable the taskbar, status bar and dde. The first two from Yap menu, the last from Windows Explorer folder options dialog. After doing this, Yap tries to open only when one moves the mouse, resizes the screen, etc.

    I don't understand why Yap would have to open the file after rendering. That is, in my opinion, a bug. Maybe Yap is trying to be sure that it has the latest version of the dvi file. If so, there are better ways to do this (obviously, native to the OS). It reminds me of standard C++ not being able to tell the size of a file without opening and moving to the end. In not, then we can ask the question why not buffering to memory or to a temporary file.

    Also, some reports (at WinEdt mail list) of TeXLive being over 25% faster than MiKTeX could be accounted by this.

    I am using the latest Yap public-available version 2.6.2639 from MiKTeX 2.6.2742.

     
  • Christian Schenk

    Logged In: YES
    user_id=67066
    Originator: NO

    Yap processes the DVI file in the background. If your file is large, it can take a while.

     
  • Hector C

    Hector C - 2007-09-25

    Logged In: YES
    user_id=1414685
    Originator: YES

    When you say process, do you mean reading for rendering? If so, why would it open and close the file? Moreover, wouldn't it be better to cache the file in memory instead of keep reading from disk? Even a disk cache (similar to Notepad) would work better. Besides, as you can see in the screen clipping, it is not reading the file, it is retrieving FileNameInformation.

    It doesn't matter whether the file is large. I have this problem in both my laptop and my desktop. My desktop is a fairly fast machine (AMD X2 5000+, 3GB RAM, 3 HDD: one for OS, one for data, one for swaping, etc.) so it should manage large files without problem.

    In your code, is there any place where the OS is asked to find out whether the rendered file has changed? Just point me to the file (yap code is big to hunt it without prior knowledge), I'll do the rest.

    Did you measure the number of accesses with FileMonitor in your system (begin some 10 seconds after rendering, you can tell when rendering has finished because there are no more calls to dvips.exe or msg.exe)?

     
  • Christian Schenk

    Logged In: YES
    user_id=67066
    Originator: NO

    Thank you for your comments. Yes, processing means "open the DVI file and read a page". The file handling will be improved in MiKTeX 2.7 (to be released later this year). If you want to take a look at the code: the page loader thread is implemented as the function DviImpl::PageLoader() in Libraries\MiKTeX\Dvi\Dvi.cpp.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks