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

Re: [NTB] Performance issues with large files

Expand Messages
  • 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 1 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 2 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 3 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 4 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.