Thread: Cream unusably slow for some Vim scripts (e.g. TOhtml)
Cream is a free, easy-to-use configuration of the Vim text editor
Brought to you by:
digitect
From: BG - B. A. <BAr...@dy...> - 2005-12-28 19:10:04
|
Try this: 1. edit a large file (my test was on 150K of syntax-highlighted source code) 2. convert it to HTML with the TOhtml Vim script: ^O:TOhtml 3. wait ... and wait ... and wait ... (I gave up after several minutes, and the file was still only 15% converted) In Vim, the same test file took 45 seconds: long, but not unusably so. I did all edits on Linux on a local drive (/tmp, which is a ramdisk). While I was waiting, Cream would alternately blink back and forth between updating the "File" menu and updating the "Window" menu. If we could defeat most or all Cream autocmds during this expensive operation, only re-enabling them (and triggering them) when we are all done, the performance could be greatly improved. Ben |
From: BG - B. A. <BAr...@dy...> - 2005-12-28 20:14:31
|
On Wed, 2005-12-28 at 15:09 -0400, BG - Ben Armstrong wrote: > If we could defeat most or all Cream autocmds during this expensive > operation, only re-enabling them (and triggering them) when we are all > done, the performance could be greatly improved. Taking a cue from our earlier performance problem report and your suggestions about what to try, I devised a manual workaround: ^O:set eventignore=all ^O:TOhtml ^O:set eventignore= Then, to retrigger the BufEnter autocmds (e.g. filetype detection/syntax highlighting,) I had to leave the newly created html output buffer and re-enter it. This time, the TOhtml conversion only took 25 seconds. Re-measuring the same test in gvim, but without the set eventignore=all, it took 27 seconds, so I must have made an error (or my test environment wasn't "clean") the first time. Neat trick. But it needs packaging. I'd hate to have to write a Cream wrapper per expensive Vim function, but that's what it's looking like to me, with my limited Vim skills. By the way, I tried disabling autocmds one group at a time: autocmd! BufEnter *, autocmd! BufWinEnter *, etc. to narrow it down to a specific group that was causing the most trouble, but I never did find the culprit. (I probably wasn't patient enough and gave up too early -- there are an awful lot of autocmds!) Ben |
From: Steve H. <dig...@mi...> - 2005-12-28 20:46:42
|
On Wed, 2005-12-28 at 15:09 -0400, BG - Ben Armstrong wrote: > Try this: > > 1. edit a large file (my test was on 150K of syntax-highlighted > source code) > 2. convert it to HTML with the TOhtml Vim script: ^O:TOhtml > 3. wait ... and wait ... and wait ... (I gave up after several > minutes, and the file was still only 15% converted) > > In Vim, the same test file took 45 seconds: long, but not unusably > so. I did all edits on Linux on a local drive (/tmp, which is a > ramdisk). > > While I was waiting, Cream would alternately blink back and forth > between updating the "File" menu and updating the "Window" menu. If > we could defeat most or all Cream autocmds during this expensive > operation, only re-enabling them (and triggering them) when we are > all done, the performance could be greatly improved. Hmm, I can't promise this will work, but I think you want something like: let g:CREAM_BEHAVE = "vim" call Cream_behave_vim() TOhtml let g:CREAM_BEHAVE == "cream" call Cream_behave_cream() That's a huge bit of overhead on the front and back, but will eliminate the Cream autocmds and other overhead. And I have no idea what will become of the converted buffer, if it disappears, maybe save it just after :TOhtml. -- Steve Hall [ digitect mindspring com ] :: Cream... something good to put in your Vim! :: http://cream.sourceforge.net |
From: Steve H. <dig...@mi...> - 2005-12-28 21:09:49
|
On Wed, 2005-12-28 at 16:13 -0400, BG - Ben Armstrong wrote: > On Wed, 2005-12-28 at 15:09 -0400, BG - Ben Armstrong wrote: > > If we could defeat most or all Cream autocmds during this > > expensive operation, only re-enabling them (and triggering them) > > when we are all done, the performance could be greatly improved. > > Taking a cue from our earlier performance problem report and your > suggestions about what to try, I devised a manual workaround: > > ^O:set eventignore=all > ^O:TOhtml > ^O:set eventignore= > > Then, to retrigger the BufEnter autocmds (e.g. filetype > detection/syntax highlighting,) I had to leave the newly created > html output buffer and re-enter it. Much better approach than my previous mail! > This time, the TOhtml conversion only took 25 seconds. Re-measuring > the same test in gvim, but without the set eventignore=all, it took > 27 seconds, so I must have made an error (or my test environment > wasn't "clean") the first time. Vim has some autocmds, maybe restrict those? > Neat trick. But it needs packaging. I'd hate to have to write a > Cream wrapper per expensive Vim function, but that's what it's > looking like to me, with my limited Vim skills. I think you're almost there. Just put those lines in a function. Then copy it into an add-on so it can be picked from a menu. One of these days this should get integrated into Cream's current Convert Text-to-HTML add-on. I wrote it to better reflect a document's leading whitespace and paragraph markings without just slamming the entire document into some pre tags. It would take some work though. > By the way, I tried disabling autocmds one group at a time: autocmd! > BufEnter *, autocmd! BufWinEnter *, etc. to narrow it down to a > specific group that was causing the most trouble, but I never did > find the culprit. (I probably wasn't patient enough and gave up too > early -- there are an awful lot of autocmds!) There are! I'm still suspicious of the filetype detection stuff. Cream relies almost entirely on Vim's detection architecture which usually re-examines the filename. But there are some window and highlighting management tasks in there, too. -- Steve Hall [ digitect mindspring com ] :: Cream... something good to put in your Vim! :: http://cream.sourceforge.net |
From: BG - B. A. <BAr...@dy...> - 2005-12-29 13:25:08
Attachments:
cream-syntax2html.vim
|
On Wed, 2005-12-28 at 16:09 -0500, Steve Hall wrote: > I think you're almost there. Just put those lines in a function. Then > copy it into an add-on so it can be picked from a menu. Something like this, then? (See attachment.) > One of these days this should get integrated into Cream's current > Convert Text-to-HTML add-on. I wrote it to better reflect a document's > leading whitespace and paragraph markings without just slamming the > entire document into some pre tags. It would take some work though. What is there to integrate? What does your text-to-HTML do that is worth preserving that mine doesn't? > There are! I'm still suspicious of the filetype detection stuff. Cream > relies almost entirely on Vim's detection architecture which usually > re-examines the filename. But there are some window and highlighting > management tasks in there, too. When I get inspired, I'll go through the entire list, then, starting with the filetype stuff. Ben |
From: Steve H. <dig...@mi...> - 2005-12-30 23:21:20
|
On Thu, 2005-12-29 at 09:24 -0400, BG - Ben Armstrong wrote: > On Wed, 2005-12-28 at 16:09 -0500, Steve Hall wrote: > > I think you're almost there. Just put those lines in a function. > > Then copy it into an add-on so it can be picked from a menu. > > Something like this, then? (See attachment.) Exactly. Tahnks, I've already added it to CVS. > > One of these days this should get integrated into Cream's current > > Convert Text-to-HTML add-on. I wrote it to better reflect a > > document's leading whitespace and paragraph markings without just > > slamming the entire document into some pre tags. It would take > > some work though. > > What is there to integrate? What does your text-to-HTML do that is > worth preserving that mine doesn't? Text2HTML preserves leading whitespace, maintains structural paragraphs, and converts illegal characters to character equivalents. It's better for lists, and document type text, while :TOhtml is better for code that is pre-formatted (as-is). > > There are! I'm still suspicious of the filetype detection stuff. > > Cream relies almost entirely on Vim's detection architecture which > > usually re-examines the filename. But there are some window and > > highlighting management tasks in there, too. > > When I get inspired, I'll go through the entire list, then, starting > with the filetype stuff. You might wait until Vim 7.0 and the corresponding Cream release, there will be huge changes at that point that may compensate. -- Steve Hall [ digitect mindspring com ] :: Cream... something good to put in your Vim! :: http://cream.sourceforge.net |
From: BG - B. A. <BAr...@dy...> - 2005-12-29 13:58:10
|
On Thu, 2005-12-29 at 09:24 -0400, BG - Ben Armstrong wrote: > What is there to integrate? What does your text-to-HTML do that is > worth preserving that mine doesn't? Sorry, I didn't really give your own text-to-HTML a close enough look before writing that. I can see now that for some users, converting proportionally spaced text to HTML & while obeying paragraph breaks is valuable. However, my own users are mostly programmers, so putting the text through <pre> isn't so bad. And I guess most Vim users (or at least Vim developers) wouldn't really care about this either, so a patch to :TOhtml itself might not be easily accepted. Doing the conversion in place in the current buffer seems like an easy way to destroy the original source file. I like the TOhtml split window, new buffer, new filename, and absence of extra dialog. (To be honest, I am still not sure what this addon's dialog is for. Whether I answer yes or no, the buffer name in the status bar remains the same.) So, I guess if I were to choose what to merge into your version, it would be this behaviour. I don't like my choice of name for this pair of addons. Maybe: Plain text to HTML Source code to HTML ASCII to text is somewhat inaccurate, as the source text could be non-ASCII (e.g. UTF-8 or Latin-1) so "Plain text" seems better. Ben |
From: Steve H. <dig...@mi...> - 2005-12-30 23:26:36
|
On Thu, 2005-12-29 at 09:58 -0400, BG - Ben Armstrong wrote: > On Thu, 2005-12-29 at 09:24 -0400, BG - Ben Armstrong wrote: > > Doing the conversion in place in the current buffer seems like an > easy way to destroy the original source file. I like the TOhtml > split window, new buffer, new filename, and absence of extra dialog. > (To be honest, I am still not sure what this addon's dialog is for. > Whether I answer yes or no, the buffer name in the status bar > remains the same.) So, I guess if I were to choose what to merge > into your version, it would be this behaviour. I think named, but unsaved buffers are confusing. By presenting the user with the initial dialog, they decide if the existing file get's an .html extension or if it stays unsaved. (Although in this case, it should probably not get a name like it does.) > I don't like my choice of name for this pair of addons. Maybe: > > Plain text to HTML Source code to HTML > > ASCII to text is somewhat inaccurate, as the source text could be > non-ASCII (e.g. UTF-8 or Latin-1) so "Plain text" seems better. "Syntax to HTML" isn't bad, although "syntax" is a particularly Vim code word. "Syntax Highlighting" might be more appropriate, as that is a pretty universal description for the feature and what gets converted. -- Steve Hall [ digitect mindspring com ] :: Cream... something good to put in your Vim! :: http://cream.sourceforge.net |