Loading ...
Sorry, an error occurred while loading the content.

RE: [NTB] Performance issues with large files

Expand Messages
  • John Shotsky
    Now that you mention it, I too have occasional slowdowns, which I long ago tracked down to needing to save more often. However, just clicking the save button
    Message 1 of 7 , Aug 17, 2009
    • 0 Attachment
      Now that you mention it, I too have occasional slowdowns, which I long ago tracked down to needing to save more often.
      However, just clicking the save button is not enough, because you can STILL undo after that. You have to save, close and
      reopen in order to clear it completely in some cases. It may be that in my case I'm working with unsaved files to start
      with - I use a lot of unnamed files for my work, as 'workspaces'. I undo and redo constantly to see what the clips have
      done and when. Eventually, I have to close them and open new documents.
      John

      From: notetab@yahoogroups.com [mailto:notetab@yahoogroups.com] On Behalf Of sisterscape
      Sent: Monday, August 17, 2009 16:51
      To: notetab@yahoogroups.com
      Subject: Re: [NTB] Performance issues with large files


      Could it be because it's caching data for the 'undo' function? Maybe a frequent save would help? Just guessing . . .

      --- On Mon, 8/17/09, Marcelo Bastos <mcblista@... <mailto:mcblista%40terra.com.br> > wrote:

      > From: Marcelo Bastos <mcblista@... <mailto:mcblista%40terra.com.br> >
      > Subject: [NTB] Performance issues with large files
      > To: notetab@yahoogroups.com <mailto:notetab%40yahoogroups.com>
      > Date: Monday, August 17, 2009, 6:42 PM
      > I have been a Notetab user for a
      > number of years, and a Notetab Pro user
      > since shortly after the release of verson 5.0 (when I
      > purchased my
      > license). I have been noticing a problem: when editing
      > largish files
      > (over 500 kb or so -- yes, that's KILObytes, not megabytes)
      > performance
      > slows to a crawl. NTP takes almost a second to process each
      > keypress,
      > scrolling gets very slow, you get the picture. Since NTP is
      > supposed to
      > be able to handle much larger files (to the order of 2 Gb
      > -- that is,
      > *four million* times larger), I have to assume that there's
      > something
      > wrong with my setup.
      >
      > Now, some further info:
      > - OK, my computer is not new. It's rather old, in fact. But
      > it's a
      > dual-CPU machine, and has 768 Mb RAM -- should be enough
      > for this job.
      > - There's plenty free RAM, as reported by the Task Manager.
      > Opening or
      > closing other programs does not seem to make any
      > difference.
      > - The issue is related to where in the file I'm looking --
      > it's
      > unnoticeable at the beginning of the file, but VERY
      > noticeable towards
      > the end of it. Yes, the SAME file. Currently I'm editing a
      > text file
      > about 1 Mb in size. Everything works normally at the top of
      > the file,
      > but the farther I advance towards the end, the slower it
      > gets.
      > - Only features that involve changing the display are
      > affected.
      > Searching/replacing is as lightning-fast as ever. But even
      > *moving the
      > cursor* gets slow towards the end of the file.
      >
      > I think it might be some sort of bad interaction with my
      > video card (an
      > ATI Radeon A9250). Has anybody else ran into anything
      > similar?
      >
      > Marcelo
      > -=-=-
      > There are *NO* absolutes and I can prove it!
      > * TagZilla 0.066 on Seamonkey 1.1.17
      >
      >
      >
      > ------------------------------------
      >
      > Fookes Software: http://www.fookes.com/
      > NoteTab website: http://www.notetab.com/
      > NoteTab Discussion Lists: http://www.notetab.com/groups.php
      >
      > ***
      > Yahoo! Groups Links
      >
      >
      > mailto:notetab-fullfeatured@yahoogroups.com <mailto:notetab-fullfeatured%40yahoogroups.com>
      >
      >
      >



      [Non-text portions of this message have been removed]
    • Marcelo Bastos
      ... No, it can t be the undo cache. I have just tested it: I closed NoteTab, reopened it, opened a 700kb file I haven t been editing in a long time, jumped to
      Message 2 of 7 , Aug 17, 2009
      • 0 Attachment
        Interviewed by CNN on 17/8/2009 21:07, John Shotsky told the world:
        > Now that you mention it, I too have occasional slowdowns, which I long ago tracked down to needing to save more often.
        > However, just clicking the save button is not enough, because you can STILL undo after that. You have to save, close and
        > reopen in order to clear it completely in some cases. It may be that in my case I'm working with unsaved files to start
        > with - I use a lot of unnamed files for my work, as 'workspaces'. I undo and redo constantly to see what the clips have
        > done and when. Eventually, I have to close them and open new documents.
        >
        No, it can't be the undo cache. I have just tested it: I closed NoteTab,
        reopened it, opened a 700kb file I haven't been editing in a long time,
        jumped to the end of the file and... there it is, slow again. As I
        mentioned, it seems to have something to do with updating the screen,
        and it has to be far from the beginning of the file.

        Marcelo

        -=-=-
        ** ERROR ** Unable to insert witty tagline.
        * TagZilla 0.066 on Seamonkey 1.1.17
      • John Shotsky
        Try copying the document to the clipboard, and paste it into a new document, save the new document, and see if it also has this problem. This often clears
        Message 3 of 7 , Aug 17, 2009
        • 0 Attachment
          Try copying the document to the clipboard, and paste it into a new document, save the new document, and see if it also
          has this problem. This often clears unnoticed characters that might be causing a problem.

          Your RAM memory is pretty small, which could easily lead to the computer using its swap file. Swap files can become
          fragmented, just like hard drives. Try deleting your swap file, reboot, then create a new one, using at least the
          recommended size. Set the minimum size and the maximum size the same - large. That way, Windows isn't busy resizing the
          swap file. Also, try placing your swap file on a drive that is different than your work drive, so it doesn't have to
          reseek to swap. Upgrading the RAM would be highly recommended, 1G minimum, 2G better (assuming XP).

          If you're using Vista, there can be other issues.
          John

          From: notetab@yahoogroups.com [mailto:notetab@yahoogroups.com] On Behalf Of Marcelo Bastos
          Sent: Monday, August 17, 2009 18:12
          To: notetab@yahoogroups.com
          Subject: Re: [NTB] Performance issues with large files


          Interviewed by CNN on 17/8/2009 21:07, John Shotsky told the world:
          > Now that you mention it, I too have occasional slowdowns, which I long ago tracked down to needing to save more often.
          > However, just clicking the save button is not enough, because you can STILL undo after that. You have to save, close
          and
          > reopen in order to clear it completely in some cases. It may be that in my case I'm working with unsaved files to
          start
          > with - I use a lot of unnamed files for my work, as 'workspaces'. I undo and redo constantly to see what the clips
          have
          > done and when. Eventually, I have to close them and open new documents.
          >
          No, it can't be the undo cache. I have just tested it: I closed NoteTab,
          reopened it, opened a 700kb file I haven't been editing in a long time,
          jumped to the end of the file and... there it is, slow again. As I
          mentioned, it seems to have something to do with updating the screen,
          and it has to be far from the beginning of the file.

          Marcelo

          -=-=-
          ** ERROR ** Unable to insert witty tagline.
          * TagZilla 0.066 on Seamonkey 1.1.17



          [Non-text portions of this message have been removed]
        • John Zeman
          I often edit a text file that s currently 1.5mb in size (and growing) and I used to have some performance problems when running a clip that contained an
          Message 4 of 7 , Aug 17, 2009
          • 0 Attachment
            I often edit a text file that's currently 1.5mb in size (and growing) and I used to have some performance problems when running a clip that contained an elaborate RegEx find/replace operation. However that problem was cured in one of the latest releases when Eric upgraded the RegEx engine.

            Other than that one thing, 1.5 mb file editing is just as fast as any small file editing is for me. For information my computer is 3.5 years old, it does have 4gb of RAM but I have also edited that same 1.5 mb file on my laptop (1Ghz RAM) with no noticeable performance problems.

            john



            --- In notetab@yahoogroups.com, Marcelo Bastos <mcblista@...> wrote:
            >
            > I have been a Notetab user for a number of years, and a Notetab Pro user
            > since shortly after the release of verson 5.0 (when I purchased my
            > license). I have been noticing a problem: when editing largish files
            > (over 500 kb or so -- yes, that's KILObytes, not megabytes) performance
            > slows to a crawl. NTP takes almost a second to process each keypress,
            > scrolling gets very slow, you get the picture. Since NTP is supposed to
            > be able to handle much larger files (to the order of 2 Gb -- that is,
            > *four million* times larger), I have to assume that there's something
            > wrong with my setup.
            >
            > Now, some further info:
            > - OK, my computer is not new. It's rather old, in fact. But it's a
            > dual-CPU machine, and has 768 Mb RAM -- should be enough for this job.
            > - There's plenty free RAM, as reported by the Task Manager. Opening or
            > closing other programs does not seem to make any difference.
            > - The issue is related to where in the file I'm looking -- it's
            > unnoticeable at the beginning of the file, but VERY noticeable towards
            > the end of it. Yes, the SAME file. Currently I'm editing a text file
            > about 1 Mb in size. Everything works normally at the top of the file,
            > but the farther I advance towards the end, the slower it gets.
            > - Only features that involve changing the display are affected.
            > Searching/replacing is as lightning-fast as ever. But even *moving the
            > cursor* gets slow towards the end of the file.
            >
            > I think it might be some sort of bad interaction with my video card (an
            > ATI Radeon A9250). Has anybody else ran into anything similar?
            >
            > Marcelo
          • Art Kocsis
            Undo after save is a NTB option. View | Options | Files | Undo After Save (uncheck box) 768 MB of RAM is quite small. Open Task manager (Control - Alt
            Message 5 of 7 , Aug 27, 2009
            • 0 Attachment
              Undo after save is a NTB option.

              View | Options | Files | Undo After Save (uncheck box)

              768 MB of RAM is quite small. Open Task manager (Control - Alt -Delete),
              choose
              the Performance tab and monitor the swap file while you are editing your
              text file.

              For optimal swap file performance, your swap file should be:
              1) On a separate physical disk drive from your editing files
              2) Fixed size (Min = Max, You should set yours to 1.5 to 2GB)
              Start | Control Panel | System | Advanced | Performance (Settings) |
              Advanced | Virtual Memory (Change) | Custom Size
              3) Contiguous. Direct your swap file to your target disk AFTER you have
              completely defragged the target disk (using most optimal setting)

              If any of your editing involves clips, use

              ^!SetScreenUpdate Off

              Updating the monitor is VERY time consuming compared to the actual editing.
              That includes just scrolling down to the next edit item. And is seriously
              affected
              by your video card and driver. You don't need a game card but a cheap
              "business"
              video card with half a GB of video RAM could easily be 10 times faster than an
              integrated motherboard chip.

              Good luck, Art

              At 08-17-2009 17:07, you wrote:
              >Now that you mention it, I too have occasional slowdowns, which I long ago
              >tracked down to needing to save more often.
              >However, just clicking the save button is not enough, because you can
              >STILL undo after that. You have to save, close and
              >reopen in order to clear it completely in some cases. It may be that in my
              >case I'm working with unsaved files to start
              >with - I use a lot of unnamed files for my work, as 'workspaces'. I undo
              >and redo constantly to see what the clips have
              >done and when. Eventually, I have to close them and open new documents.
              >John
              >
              >From: <mailto:notetab%40yahoogroups.com>notetab@yahoogroups.com
              >[mailto:notetab@yahoogroups.com] On Behalf Of sisterscape
              >Sent: Monday, August 17, 2009 16:51
              >To: <mailto:notetab%40yahoogroups.com>notetab@yahoogroups.com
              >Subject: Re: [NTB] Performance issues with large files
              >
              >Could it be because it's caching data for the 'undo' function? Maybe a
              >frequent save would help? Just guessing . . .

              ----------


              No virus found in this outgoing message.
              Checked by AVG - www.avg.com
              Version: 8.5.409 / Virus Database: 270.13.69/2328 - Release Date: 08/26/09 12:16:00


              [Non-text portions of this message have been removed]
            Your message has been successfully submitted and would be delivered to recipients shortly.