Hi all, I have a class that holds a large xml document (100,000+ nodes) which is retrieved from a web server and parsed amazing quickly. However, when I perform an XPath query to select nodes from the document, this can take a few seconds. I currently display a wait animation whilst the xpath query is processing, but the processing of the XPath seems takes up 100% of the CPU and the gif animation is not updated. Baring in ming that I am relatively new to javascript and I am a c# programmer, I was wondering if it is possible to process the xpath query in a separate thread. Is it possible to create threads in javascript ? Are there any extensions to prototype that can help. Thanks for any help. Regards, Matt --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Hey there, lummie a écrit :> Baring in ming that I am relatively new to javascript and I am a c# > programmer, I was wondering if it is possible to process the xpath > query in a separate thread. Is it possible to create threads in > javascript ? Are there any extensions to prototype that can help.AFAIK, script execution in any particular viewport is single-threaded. That being said, I must say I question the relevance of your 100,000+ node loading strategy on the client side. Massive data processing is server side business, at least in the current state of the technology. -- Christophe Porteneuve aka TDD tdd-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
I am loading such a large amount of data due to application requirement. The applciation has to be able to display a hierarchy of 10s of thousands of items. Traditional trees approaches (e.g. an asp.net rendering for example) are not quick enough, you expand an item that has 30,000 children and they try and add them all to hte HTML dom. The tree I am currently prototyping, loads the hierarchy as an XML document and then only renders a viewport of it to the html document. Effectively, no matter what the size of the hierarchy on about 20 nodes are written to the dom. As the user scrolls the virtual viewport, I jsut replace the 20 nodes as the viewport moves. It is performant, from the point of view of retieving the xml document from the server, loading into the XMLdom, and scrlling the viewport but the intial selection of nodes via an xpath statement, takes time (an acceptable time) but seems to lock the browsers thread so my progress indicators don''t update. Hence, the question, If I can launch the XPpath query on a seperate thread and raise an event back to the tree when it is complete, it will hopefully stop the dom rendering thread being blocked. Hope that clarifies things. On 13 Apr, 09:43, Christophe Porteneuve <t...-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org> wrote:> Hey there, > > lummie a écrit : > > > Baring in ming that I am relatively new to javascript and I am a c# > > programmer, I was wondering if it is possible to process the xpath > > query in a separate thread. Is it possible to create threads in > > javascript ? Are there any extensions to prototype that can help. > > AFAIK, script execution in any particular viewport is single-threaded. > > That being said, I must say I question the relevance of your 100,000+ > node loading strategy on the client side. Massive data processing is > server side business, at least in the current state of the technology. > > -- > Christophe Porteneuve aka TDD > t...-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---
Hi lummie, You''re right to avoid putting 10,000 DOM nodes into the page, but even loading that much data behind the scenes will put quite a load on the browser (especially IE!!). Is it possible to load the data incrementally as the user scrolls (think of Google Maps as a useful analogy - it loads extra images in anticipation of your scrolling, and sometimes there''s a noticeable lag, but mostly it works smoothly). The freeze-up that you''re seeing could be down to any one of three things: 1. loading the XML document 2. running the XPath query 3. rendering a subset of the data on screen (unlikely, as the suibset is small) I''d recommend you reduce the problem to a simple test page, in which you can perform 1, 1+2 or 1-3. Then set up some sort of timer to record how long each step takes, and have a look in Task Manager at the footprint of the browser in MBytes. Then you will know where the problem lies, I would hope. My gut feeling is that loading the XML doc is enough to bring IE to its knees, but a decent set of numbers and measurements are much better than the gut feelings of me or anyone else :-) HTH Dave On Friday 13 April 2007 09:59, lummie wrote:> I am loading such a large amount of data due to application > requirement. The applciation has to be able to display a hierarchy of > 10s of thousands of items. Traditional trees approaches (e.g. an > asp.net rendering for example) are not quick enough, you expand an > item that has 30,000 children and they try and add them all to hte > HTML dom. The tree I am currently prototyping, loads the hierarchy as > an XML document and then only renders a viewport of it to the html > document. Effectively, no matter what the size of the hierarchy on > about 20 nodes are written to the dom. As the user scrolls the > virtual viewport, I jsut replace the 20 nodes as the viewport moves. > > It is performant, from the point of view of retieving the xml document > from the server, loading into the XMLdom, and scrlling the viewport > but the intial selection of nodes via an xpath statement, takes time > (an acceptable time) but seems to lock the browsers thread so my > progress indicators don''t update. > > Hence, the question, If I can launch the XPpath query on a seperate > thread and raise an event back to the tree when it is complete, it > will hopefully stop the dom rendering thread being blocked. > > Hope that clarifies things. > > On 13 Apr, 09:43, Christophe Porteneuve <t...-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org> wrote: > > Hey there, > > > > lummie a écrit : > > > Baring in ming that I am relatively new to javascript and I am a c# > > > programmer, I was wondering if it is possible to process the xpath > > > query in a separate thread. Is it possible to create threads in > > > javascript ? Are there any extensions to prototype that can help. > > > > AFAIK, script execution in any particular viewport is single-threaded. > > > > That being said, I must say I question the relevance of your 100,000+ > > node loading strategy on the client side. Massive data processing is > > server side business, at least in the current state of the technology. > > > > -- > > Christophe Porteneuve aka TDD > > t...-x+CfDp/qHev2eFz/2MeuCQ@public.gmane.org > > > > > -- > This email has been verified as Virus free > Virus Protection and more available at http://www.plus.net--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Spinoffs" group. To post to this group, send email to rubyonrails-spinoffs-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-spinoffs-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-spinoffs?hl=en -~----------~----~----~----~------~----~------~--~---