Why can Bakoma process .tex files so fast?

Question

Bakoma is a LaTeX Editor which has the real-time preview on Windows. On Linux, one has Gummi which has a similar feature and on Windows, I use WinEdt with Sumatra PDF together with an AutoIt script to do this. When the .tex is small, then both Gummi and my method gives 99.99% real-time preview feature, namely the delay between the typing and the appearance of updated PDF content is less then 0.5 second (even more, 0.2 second, I think). When the .tex file gets bigger, the delay gets large also. Furthermore, because the frequent compiling, the CPU becomes much buiser.

But Bakoma has no such problems. Anybody knows how Bakoma can process .tex files so fast? Is it possible to make MikTeX or TexLive to speed up by the similar mechanic ?

---

Since someone ask the methods I mentioned, I need to share it by answering my own question, sorry.

First of all, for Gummi on Ubuntu:

After install Gummi, open /home/(user account name)/.config/gummi/gummi.cfg Then change compile_timer to 0, but keep compile_scheme = on_idle. Now for small .tex files, you have real-time preview. Notice that if you change to compile_scheme = real-time, then CPU becomes very busy even the .tex file is small.

For WinEdt + SumatraPDF + MiKTeX on Windows ( I use MiKTeX 2.9 on Windows 7 64-bit) :

1. In WinEdt, go Options\Execution\Modes. On Accessories, choose PDFLaTeX. On Console Attributes on the right side, choose Background Window, Hidden Window, WinEdt Console but not Pause / Do not Hide the Windo. On Process Folw, only select No Interaction and press OK

2. Open C:\Program Files (x86)\WinEdt Team\WinEdt 6\Exec\ExeCompiler.edt. Remove the following:

Prompt("Another Application is already running in WinEdt's Console.> Terminate the application or wait for the execution to finish!");

Replace ShowConsole(1) by ShowConsole(-1), there are 4 places to replace. Replace FocusConsole(1); by FocusConsole(-1);, ther are 3 places to replace. Save the file.

1. In WinEdt, go Options\Options Interface. On Menus and Toolbar choose Main Menu. Add SHORTCUT="120::F9" after MACRO="Exe('%b\Exec\TeX\PDFLaTeX.edt');" and add SHORTCUT="119::F8" after MACRO="SaveDoc;". Remember to remove the same shortcuts appear in the original file. Save the file and reload it.

2. Install AutoIt. Create the following script

    $size = FileGetSize("C:\test.tex")
    While 1
        sleep(40)
        If WinActive("WinEdt 6.0", "C:\test.tex") Then
            Send("{F8}")
            $newsize = FileGetSize("C:\test.tex")
            If $newsize <> $size AND ProcessExists("pdflatex.exe") = 0 Then 
                $size = $newsize
                Send("{F9}")
            EndIf
        EndIf   
    WEnd
   

Then after running this script, when you edit your C:\test.tex, you have the real-time preview. One can change the script to get the .tex filename you open, but I haven't done this yet.

---

Update:

Using the Forward search function, I get a function similar to "Auto Scroll in the viewer" in Gummi. Please check the demonstration video on youtube

Demonstration of Real-Time Preview

Answer 1

According to their website it can do this because it only formats one page at a time.

Long documents -- TeX Word Performance
I would like to clarify one misinformation that 'BaKoMa TeX Word is efficient only for short documents, because it runs TeX on background'.

In one side it is true that BaKoMa TeX Word runs TeX to display document. This approach provides True WYSWIWYG Preview (100 % compatibility with output of native LaTeX). However, BaKoMa TeX Word has no degradation of performance at editing long documents. Our users edit books of 500 and more pages and enjoy that speed is even better then at editing one-page document !!!
The reason of this scalability is that only one page of document is reformatted at editing document.

How it does this, I don't know. They do claim what is shown on the screen is equivalent to what will be printed on the pages. I doubt that that is entirely true. Perhaps the look (fonts, kerning etc.) of the document is exactly the same, but the exact location on the page is influenced by more than only the content of the current page.