BBEdit slow large file opening

[Martin Obrist]

Dear BBEditers

It strikes me, that BBEdit (10.5.10) is becoming painfully slow when opening, editing and saving large files, 11 MB text file that is, 11 Mio characters, 1.2 Mio words. Not sure when this came up, via BBEdit update or Mavericks, but earlier BBEdit was always very snappy. Any similar experiences?

Regards

Martin



Dr. Martin K. Obrist ^v^
^v^
Swiss Federal Research Institute WSL
Biodiversity and Conservation Biology
CH-8903 Birmensdorf, Switzerland
MG D 52 phone: ++41 44 739 24 66 fax: ++41 44 739 22 15
E- mailto:martin...@wsl.ch WWW http://www.wsl.ch/fe/biodiversitaet/

[mORA]

Same here.

* * *

[Lawrence San]

I'm still on BBEdit 9, on a fast Mac with lots of RAM... and used various older versions going many years back... and I've always found it to be slow in opening large files. Luckily I rarely use it for that purpose.

--
This is the BBEdit Talk public discussion group. If you have a
feature request or would like to report a problem, please email
"sup...@barebones.com" rather than posting to the group.
Follow @bbedit on Twitter: <http://www.twitter.com/bbedit>

---
You received this message because you are subscribed to the Google Groups "BBEdit Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bbedit+un...@googlegroups.com.
To post to this group, send email to bbe...@googlegroups.com.

[Thomas Mai]

Became curious – had to try that by myself...
For testing I used a 129 MB SQL-Dump on my new 3.5 GHz i7 iMac with 32 GB RAM, Fusion Drive and Mavericks.

BBEdit:
~2 sec to open, smooth scrolling, everything's fine. Fantastic! Could hardly believe that.

Textmate 2:
~12 sec to open, smooth scrolling, pausing when resizing the window, syntax highlighting was fast on the first 100.000 lines or so, but then took minutes for the rest of the file.

Textmate 1:
Almost the same as TM 2, but beach ball for many seconds when jumping around via "Go to line"

Coda 2:
~15 sec to open, no syntax highlighting, every scrolling showed the beach ball, unusable

PhpStorm 7.1:
"Too large" message and that's it.

Sublime Text 2:
~1,5 min to load, but then super fast and responsive incl. syntax highlighting and minimap


Another test with ~100 K HTML Code:
BBEdit: Super fast!
Textmate: Syntax highlighting needs some time...
Sublime: ~3 sec to load, but then really fast
Coda: No syntax highlighting, lazy, sticky, no fun
Dreamweaver CS 5.5: ~18 secs to load, then a min or so beach ball after scrolling to end of page... but then ok, even in Code/Design split-view

[Steve Piercy]

SSD or Fusion drives dramatically improve file opening speed
over spinny HDs. On my old klunky Mac with a plain old HD, I go
make coffee while the file opens. On my new Mac with an SSD, I
take fewer coffee breaks.

--steve


On 4/20/14 at 4:45 PM, medi...@googlemail.com (Thomas Mai) pronounced:

------------------------
Steve Piercy, Soquel, CA

[Bruce Van Allen]

Yes, some of us don't have the latest.

However, I tried opening some large text files on an external
7200 RPM external hard drive attached to my 2010 iMac 2.93GHz i7
with 12 MB RAM. BBEdit opened a 70.5 MB file in 1 second, and a
186.8 MB file in 2.5 seconds.

Then I tried opening those same two files over my LAN with a Mac
Mini 2010 2.66 GHz Core 2 Duo with 8MB RAM: 70.5 MB in 11
seconds, 186.8 MB in 31 seconds. Finally, I copied the larger
one to the Mini's Desktop, dragged its icon onto BBEdit on the
dock (already running): under 6 seconds.

In all cases, scrolling, jump to the end of file, etc, were all
immediately smooth and fast.

This is with BBEdit 10.5.10, OS X 10.9.2 (Mavericks); no SSDs on
either machine. I don't have those other editors that Thomas tested.

In years past, people noticed that having BBEdit set to wrap
lines would cause some slow-downs, especially when scrolling. I
routinely don't have line-wrapping turned on, so I haven't
recently tested whether that's still a factor.

Clearly from some of the posts, our mileage is varying. I wonder
if it's the amount of RAM...

Best Regards,

- Bruce

_bruce__van_allen__santa_cruz_ca_

[Steve Piercy]

On 4/20/14 at 9:11 PM, b...@cruzio.com (Bruce Van Allen) pronounced:

>In years past, people noticed that having BBEdit set to wrap
>lines would cause some slow-downs, especially when scrolling. I
>routinely don't have line-wrapping turned on, so I haven't
>recently tested whether that's still a factor.

I would assume that anything requiring more cycles to draw on
screen will slow down performance. Syntax coloring might slow
down rendering, too.

>Clearly from some of the posts, our mileage is varying. I
>wonder if it's the amount of RAM...

Open Activity Monitor, then your file. What happens to RAM usage?

--steve

[Tom Robinson]

Don't know if it's still the case, but a version or 2 ago the default for Soft Wrap Text made a huge difference to the speed of BBEdit opening large files.

[Lawrence San]

Ah, that must be why large files open slowly for me: I always keep soft wrapping and syntax coloring on. By the way, why do so many coders prefer to keep soft wrapping off? My code lines are usually manually hard-wrapped anyway, but if soft wrapping is disabled my block comments (and some other lines) tend to get cut off by the edge of the window. I'm guessing that there's some disadvantage to soft wrapping (in addition to slower file opening) that I don't understand.

Lawrence San
Business Writing: Santhology.com
Cartoon Stories for Thoughtful People: Sanstudio.com

[Charlie Garrison]

Good morning,

On 22/04/14 at 11:23 AM -0400, Lawrence San

<lawre...@gmail.com> wrote:

>By the way, why do so many coders prefer to keep soft wrapping off?

Personally, I would reverse that question; why do you prefer
soft wrapping on? (Yes, you've already answered it.)

>My code lines are usually manually hard-wrapped anyway, but if soft
>wrapping is disabled my block comments (and some other lines) tend to
>get cut off by the edge of the window.

I would argue that's where the problem is. For "code" lines; I
use one of the formatter/tidier scripts to 'clean' the code,
which will also keep it under MAXCHAR line length.

For block comments, just run it through hard-wrap, then apply
'comment'. (I think there is also a version of wrapping that
takes into account comment characters.)

To actually answer your question, for me it is simply that I
will view/edit the code with tools other than BBEdit. Having
hardwrap is better than relying on current tool's implementation
of softwrap.

>I'm guessing that there's some disadvantage to soft wrapping (in
>addition to slower file opening) that I don't understand.

Lack of control. All coders I've known prefer to control line
breaks. Now, *where* to break the lines... that is certainly debated.


Charlie

--
Make-Tracks Secure Hosting Pty Ltd <http://www.make-tracks.com>
PO Box 141 <ad...@make-tracks.com>
Windsor NSW 2756 Australia Ph: +61 2 9043 0613

** Take Control of Your Website **

[Lawrence San]

Charlie Garrison <garr...@zeta.org.au> wrote:

For block comments, just run it through hard-wrap, then apply 'comment'.

But if you then go back later and make a substantial edit to your hard-wrapped block comments, don't they turn into a mess? I've tried that, and ended up manually dragging numerous line fragments around to get it back into a reasonable block form, which seemed like more trouble than it's worth.

[Oliver Taylor]

On 23 Apr 2014, at 3:15 PM, Lawrence San <lawre...@gmail.com> wrote:

But if you then go back later and make a substantial edit to your hard-wrapped block comments, don't they turn into a mess? I've tried that, and ended up manually dragging numerous line fragments around to get it back into a reasonable block form, which seemed like more trouble than it's worth.

BBEdit does this automatically. Try “Text > Hard Wrap…” on a messed-up comment block.

[Alex Satrapa]

BBEdit can gracefully handle rewrapping comments if they are in BBEdit’s preferred comment style for the language selected for a given document.

I had a rather messy comment to clean up after having rewritten some comments in PHP code that were written as such:

/* blah blah blah

 * blah blah blah

 * blah blah blah

 * blah blah blah

 */

BBEdit’s preferred comment scheme for PHP appears to be this:

// blah blah blah

// blah blah blah

// blah blah blah

// blah blah blah

In the latter format, if you modify the comment to be something like this:

// blah blah blah

// blah foobar qux fribble

// blah blah blah

// blah frob qux blurgle

BBEdit will correctly rewrap to something like this:

// blah blah blah

// blah foobar

// qux fribble

// blah blah blah

// blah frub qux

// blurgle

If the comments are in a non-preferred format you’ll end up with something more like this:

/* blah blah blah

* blah foobar *

qux fribble *

blah blah blah *

blah frub qux *

blurgle */

Good luck, have fun =)

Alex

[Charlie Garrison]

Good morning,

On 23/04/14 at 6:15 PM -0400, Lawrence San

No, I don't have that problem, but my coding style is most
likely different from yours. I try to stay with commonly
accepted styles since code I write gets shared around. BBEdit
seems fine with common coding styles (or comment styles).

[Lawrence San]

On Wed, Apr 23, 2014 at 6:30 PM, Oliver Taylor <oliver...@me.com> wrote:

BBEdit does this automatically. Try “Text > Hard Wrap…” on a messed-up comment block.

Wow, you're right. I didn't know BBEdit could do that. Nice. Frankly I'm still not sure why I'd be better off hard-wrapping the document, but this opens that up as more of a possibility.

[mkowsl]

Self-answer: Soft-wrapping does not affect the speed, however, on a fresh account the file opens in a snap with BBE. Thus, some gimmicks I've installed in my regular account must be the culprit - havn't found out which yet....Regards, Martin