<blockquote>
<p>the main problem has to do with dynamic line sizes</p>
</blockquote>
<p>Naw, Scintilla uses a contiguous (gap) buffer to store the data. I believe this is what Emacs and other editors do, as it's a fair trade-off for typical text file operations.</p>
<blockquote>
<p>Geany/Scintilla doesn't know where the next line will end so it has to scan every character to keep its loaded undo buffer</p>
</blockquote>
<p>It does scan every character to locate line-endings, which it caches in a side table to make other operations much more efficient. This isn't really related to undo buffer.</p>
<blockquote>
<p>I'm not sure why you guys reported that it consumes twice the size of the file size.</p>
</blockquote>
<p>In addition to the side table for the line offset information, it also keeps a separate gap buffer which holds a byte for the styling information for each character. This is why it's at least twice the size in memory. Also when Geany loads a file, I believe it loads it into a string, sends it to Scintilla, and then frees it, so it uses 2x the total size there too. In addition, internally when Scintilla re-allocates it's internal buffers/tables, it most likely causes 2x memory overhead (in addition to the gap buffer's extra capacity), so it can copy data from old memory to new memory. I think this is what <a href="https://github.com/elextr" class="user-mention">@elextr</a> is referring to.</p>
<blockquote>
<p>Not sure if it would be possible to improve geany to using a static line size setting</p>
</blockquote>
<p>It wouldn't, and it would also break files with long-lines (ex. minified JS or whatever).</p>
<blockquote>
<p>possibly the dynamic undo buffer to ensure memory is not allocated if its not necessary.</p>
</blockquote>
<p>It would be possible to optimize the undo buffer by storing the delta/diff between the current buffer vs the top of the undo buffer on reload, but it would make a different set of tradeoffs for time vs space which may not be as optimal for typical text file editing needs.</p>
<blockquote>
<p>It would also be nice to warn the user if Geany is in danger of running out of memory. Then a user could commit changes as necessary and reset the undo buffer while not continuing to consume more memory.</p>
</blockquote>
<p>Agree, but there are many cases where it's not possible. Inside GLib when it tries to allocate memory, if it fails, it aborts the process, which is a fairly reasonable thing to do on decent modern operating systems. It may (or not) be possible to gracefully handle OOM conditions inside Scintilla as this PR is about though, assuming when the Scintilla call returns, it leaves enough memory for Geany to allocate a new dialog window and format a string into it's message.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/geany/geany/issues/1569#issuecomment-320129497">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABDrJ_qEFul1bt0uGbkkPRft9t7S4kCEks5sUm7SgaJpZM4OtGp5">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ABDrJ3LuMupoA4ds6b7_lmP0sedRIZn0ks5sUm7SgaJpZM4OtGp5.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/geany/geany/issues/1569#issuecomment-320129497"></link>
  <meta itemprop="name" content="View Issue"></meta>
</div>
<meta itemprop="description" content="View this Issue on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/geany/geany","title":"geany/geany","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/geany/geany"}},"updates":{"snippets":[{"icon":"PERSON","message":"@codebrainz in #1569: \u003e the main problem has to do with dynamic line sizes\r\n\r\nNaw, Scintilla uses a contiguous (gap) buffer to store the data. I believe this is what Emacs and other editors do, as it's a fair trade-off for typical text file operations.\r\n\r\n\u003e Geany/Scintilla doesn't know where the next line will end so it has to scan every character to keep its loaded undo buffer\r\n\r\nIt does scan every character to locate line-endings, which it caches in a side table to make other operations much more efficient. This isn't really related to undo buffer.\r\n\r\n\u003e I'm not sure why you guys reported that it consumes twice the size of the file size. \r\n\r\nIn addition to the side table for the line offset information, it also keeps a separate gap buffer which holds a byte for the styling information for each character. This is why it's at least twice the size in memory. Also when Geany loads a file, I believe it loads it into a string, sends it to Scintilla, and then frees it, so it uses 2x the total size there too. In addition, internally when Scintilla re-allocates it's internal buffers/tables, it most likely causes 2x memory overhead (in addition to the gap buffer's extra capacity), so it can copy data from old memory to new memory. I think this is what @elextr is referring to.\r\n\r\n\u003e Not sure if it would be possible to improve geany to using a static line size setting\r\n\r\nIt wouldn't, and it would also break files with long-lines (ex. minified JS or whatever).\r\n\r\n\u003e possibly the dynamic undo buffer to ensure memory is not allocated if its not necessary.\r\n\r\nIt would be possible to optimize the undo buffer by storing the delta/diff between the current buffer vs the top of the undo buffer on reload, but it would make a different set of tradeoffs for time vs space which may not be as optimal for typical text file editing needs.\r\n\r\n\u003e It would also be nice to warn the user if Geany is in danger of running out of memory. Then a user could commit changes as necessary and reset the undo buffer while not continuing to consume more memory.\r\n\r\nAgree, but there are many cases where it's not possible. Inside GLib when it tries to allocate memory, if it fails, it aborts the process, which is a fairly reasonable thing to do on decent modern operating systems. It may (or not) be possible to gracefully handle OOM conditions inside Scintilla as this PR is about though, assuming when the Scintilla call returns, it leaves enough memory for Geany to allocate a new dialog window and format a string into it's message."}],"action":{"name":"View Issue","url":"https://github.com/geany/geany/issues/1569#issuecomment-320129497"}}}</script>