fnDraw (whole table) vs. fnUpdate/Add/Delete (row by row)

fnDraw (whole table) vs. fnUpdate/Add/Delete (row by row)

GregPGregP Posts: 487Questions: 8Answers: 0
edited May 2011 in General
Hey all,

Trying for the most efficient way to update my table based on polling:

- My application polls for new data with varying degrees of frequency depending on which set of data is being requested. Suffice it to say, at its fastest, the table is being updated every 2 seconds.

- I currently use server-side processing, and I can expect to see up to 100 records at any given time. Since I'm using server-side, each fnDraw requests the entire set of 100 rows, and sends them back in the specified order.

- Each row is constantly updating with a task progress bar and other ever-changing statistics.

- During the initialization (and subsequent fnDraw calls), I use fnRowCallback extensively to do various user-facing things (for example, I take a URL from aData[5] and pass it into a click event listener that listens from the first VISIBLE column (td:eq(0)) ). The progress is displayed by taking the raw percentage from aData and setting it as the width of a div. Suffice it to say, there's a LOT of per-row processing going on with each fnDraw.

So, the question is this:

Can a system based around fnUpdate (and its siblings) handle all this extra processing? I can use fnGetData, compare it to the incoming JSON (fetched with each poll), and update rows accordingly in theory. But if I pass that data into the new row, won't I still have to call utility functions that do all the user-facing stuff like turn the percentage into a progress bar, etc?

Given on at least one of my table types, all rows are going to have at least 3 cells needing updating, and that the rapid turnover of rows (what was row 2 becomes row 1 very quickly most of the time) will mean an entire row needs updating, am I looking at an efficiency opportunity with fnUpdate, or an efficiency nightmare? Efficiency of the code, of course; in terms of human efficiency it's already 'working' with fnDraw and I just need to decide if it's worth sacrificing some human efficiency by spending time refactoring.

So I guess really 2 things:
1. Can it even be done with fnUpdate (etc), since I need to process the data into a new view
2. Is it worth my time?

Replies

  • allanallan Posts: 63,180Questions: 1Answers: 10,411 Site admin
    Not even 24 hours and on the second page already!

    1. Yes this can be done - you are correct that you would need to call your utility functions after doing the cell update (and make sure you don't call fnDraw), so there is a bit of work there - but it is certainly possible.

    2. I'm honestly not sure. There are three points which I think will be slow on the system:

    a. The http requests going out every 2 seconds - the server needs to be able to respond quickly
    b. Dom updates - you want to keep this to a minimum
    c. Time spent rendering and the like

    I think the answer can only be found by trying it. My instinct is that you want to have the server keep track of a Diff between each set of information it sends out, so it can send to the client only the information that needs to be updated. Then the client has less work to do and less info is going over http. But it's more development work...

    Allan
  • GregPGregP Posts: 487Questions: 8Answers: 0
    Thanks for the reply, Allan!

    Since I'm not developing the server side, I'm not likely to get that diff. I think I'll stick with fnDraw since it is actually working. I'll solve the problem of row-by-row later if it ever comes up again.
  • allanallan Posts: 63,180Questions: 1Answers: 10,411 Site admin
    Heh - it's the least work :-) I guess the other option would be to keep track of the diff client-side, but that it's possible that might be slower that just doing the full redraw (although I suspect probably not - although it might be close). It's a tricky one with so fast an update and DOM access being so slow. When the app is complete that might be the time to start optimising aspects of the whole system.

    Allan
This discussion has been closed.