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

Re: Datatable performance with large number of records

Expand Messages
  • zleatherman
    Here s a simple solution that will give you a little bit more performance: http://www.zachleat.com/web/2007/12/27/faster-yui-datatable-with-5-lines-of-code/
    Message 1 of 7 , Jan 2, 2008
      Here's a simple solution that will give you a little bit more performance:

      http://www.zachleat.com/web/2007/12/27/faster-yui-datatable-with-5-lines-of-code/

      The holy grail would be to use the HTML Table YUI DataTable type if
      YUI didn't erase your existing markup and start from scratch. I've
      put up a feature request on the sourceforge tracker, if you leave a
      note of support there, maybe we'll get it into the next release.
      Here's the link:

      http://sourceforge.net/tracker/index.php?func=detail&aid=1862771&group_id=165715&atid=836479
    • Satyam
      You have two different sugestions, one on your blog and a different one in SourceForge. The later is quite extensive so I wasn t able to try it. I tried the
      Message 2 of 7 , Jan 3, 2008
        You have two different sugestions, one on your blog and a different one in
        SourceForge. The later is quite extensive so I wasn't able to try it.

        I tried the sugestion in your blog with a table of mine which takes about
        7.5 seconds to draw. The gain was less than 2%.

        It doesn't work if you have any column declared as resizeable as some part
        of the code to place the drag and drop handles relies on the table to
        actually be part of the document. It was just a random discovery since the
        table I tried had its columns set to resizeable. Paging (drawing the page
        links) is unaffected. I can't imagine other pitfalls, most other features I
        can think of have no relation to the DataTable being actually in the
        document so they shouldn't be affected. I can't tell with the version you
        posted on SourceForge.

        It is far more efficient (if possible) to paginate, that drops times for the
        same table to 0.7 seconds, an almost 11:1 reduction in time, which should be
        no surprise since the DataTable I tried happens to be 11 pages long so the
        more pages the larger the gain. By the way, retrieving the data for the
        database table, transmitting it, parsing and initial DataTable setup takes
        almost half a second which was not included in the above. There is a basic
        penalty of almost 30ms per row no matter how you draw it so the less rows
        there are to draw, the better. I tried with different rowsPerPage and it is
        more or less linear above 10 rowsPerPage, then the overhead starts to
        matter. There is almost no overhead on successive pages, it is all drawing
        time. (all times as measured in my machine so they are simply valid in
        relation to one another).

        In the version in SourceForge you seem to be bypassing the DataTable when
        drawing each column because you already have one drawn since you had your
        server to draw it, that is, you are enhancing existing markup. This
        excludes other data transfer formats such as JSON, which is what I use, or
        XML, another reason why I can't try it.

        So, yes, drawing each row takes time and if you can avoid it, that is good.
        Nevertheless, the solution from your blog does not gain much and the one in
        SourceForge is limited to just one data source type and I would guess it
        wouldn't take any cell formatter in the column definitions so, forget about
        checkboxes, radios, dropdowns and such.

        Satyam




        ----- Original Message -----
        From: "zleatherman" <zachleatherman@...>
        To: <ydn-javascript@yahoogroups.com>
        Sent: Thursday, January 03, 2008 12:43 AM
        Subject: [ydn-javascript] Re: Datatable performance with large number of
        records


        > Here's a simple solution that will give you a little bit more performance:
        >
        > http://www.zachleat.com/web/2007/12/27/faster-yui-datatable-with-5-lines-of-code/
        >
        > The holy grail would be to use the HTML Table YUI DataTable type if
        > YUI didn't erase your existing markup and start from scratch. I've
        > put up a feature request on the sourceforge tracker, if you leave a
        > note of support there, maybe we'll get it into the next release.
        > Here's the link:
        >
        > http://sourceforge.net/tracker/index.php?func=detail&aid=1862771&group_id=165715&atid=836479
        >
        >
        >
        >
        >
        > Yahoo! Groups Links
        >
        >
        >
        >
        >
        > --
        > No virus found in this incoming message.
        > Checked by AVG Free Edition.
        > Version: 7.5.516 / Virus Database: 269.17.13/1206 - Release Date:
        > 01/01/2008 12:09
        >
        >
      • Mukesh Jain
        Satyam Can you please suggest what should be optimum number of records to load in datatable without implementing paging. After this limit we should go for
        Message 3 of 7 , Jan 23, 2008
          Satyam

          Can you please suggest what should be optimum number of records to
          load in datatable without implementing paging. After this limit we
          should go for paging.

          Thanks
          Mukesh Jain
        • Satyam
          It is a subjective issue, I don t think anyone can give you any hard data on this. The performance depends more on the number of cells and the complexity (if
          Message 4 of 7 , Jan 23, 2008
            It is a subjective issue, I don't think anyone can give you any hard data on
            this. The performance depends more on the number of cells and the
            complexity (if any) of the formatting of each than on the plain number of
            recods. People migrating from slow systems might find anything acceptable.
            If you are still some time away from deployment or from any large number of
            records, the performance of the DataTable was one of the points that was
            supposed to see improvements in the next version so you might want to keep
            paging as an ace in your sleeve until you see it is really needed.

            Satyam

            ----- Original Message -----
            From: "Mukesh Jain" <mukesh1.jain@...>
            To: <ydn-javascript@yahoogroups.com>
            Sent: Wednesday, January 23, 2008 6:26 PM
            Subject: [ydn-javascript] Re: Datatable performance with large number of
            records


            > Satyam
            >
            > Can you please suggest what should be optimum number of records to
            > load in datatable without implementing paging. After this limit we
            > should go for paging.
            >
            > Thanks
            > Mukesh Jain
            >
            >
            >
            >
            > Yahoo! Groups Links
            >
            >
            >
            >
            >
            > --
            > No virus found in this incoming message.
            > Checked by AVG Free Edition.
            > Version: 7.5.516 / Virus Database: 269.19.9/1238 - Release Date:
            > 22/01/2008 20:12
            >
            >
          Your message has been successfully submitted and would be delivered to recipients shortly.