Sochettra / dynatree

Automatically exported from code.google.com/p/dynatree
0 stars 0 forks source link

Load time issue #182

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Implement your AJAX loading example
2. Load the page using attached data

See attached image which shows the times of each debug line.  It also includes 
loading of initial data.

We would expect this to load faster, is it configured wrong or anything?

Version: 1.1.0

Windows Vista + Firefox 3

Original issue reported on code.google.com by bjohnson...@gmail.com on 23 Feb 2011 at 10:48

Attachments:

GoogleCodeExporter commented 8 years ago
[deleted comment]
GoogleCodeExporter commented 8 years ago
Well I tried your benchmarks again and they seem fairly slow as well.

On first load, opening the 100 node examples seems fairly slow in firefox 3.  
Something like 5-6 seconds or so shown by firebug.

Original comment by bjohnson...@gmail.com on 23 Feb 2011 at 11:17

GoogleCodeExporter commented 8 years ago
Seems to work much better in IE and Chrome.  Isolated to firefox 3 perpages? 

Using:
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.2) Gecko/20100316 
Firefox/3.6.2 ( .NET CLR 3.5.30729; .NET4.0C)

On Vista 64bit.

Original comment by bjohnson...@gmail.com on 23 Feb 2011 at 11:35

GoogleCodeExporter commented 8 years ago
I tried your sample with FF 3.6.13 / Vista on an Athlon 5000 (see attached 
timings).
Took < 0.85 seconds here. (Loading the json file locally).

Typically most of the time (and memory usage) is taken by the DOM rendering.
Dynatree defers this step until the nodes become visble for the first time, so 
it is more efficient to use a hierarchical structure.
This sample contains one branch with 10k loaded nodes:
http://wwwendt.de/tech/dynatree/doc/test-bench.html

Original comment by moo...@wwwendt.de on 24 Feb 2011 at 7:22

Attachments:

GoogleCodeExporter commented 8 years ago
Hi,

Your http://wwwendt.de/tech/dynatree/doc/test-bench.html

Loads slow for us on Firefox as well so I think we can just use it for the 
example instead of our own code.

What can I send you to help debug this issue?  I understand you can't reproduce 
it but it is a problem for us.  It works fine in IE/Chrome but FF is the issue. 
 Any FF plugins or anything to check?

Original comment by bjohnson...@gmail.com on 24 Feb 2011 at 5:08

GoogleCodeExporter commented 8 years ago
You Could send the results of Firebugs console-profiling and Network Tabs
Thx

Original comment by moo...@wwwendt.de on 24 Feb 2011 at 6:33

GoogleCodeExporter commented 8 years ago
I hope these help.  Let me know if there is anything I can do or anything else 
you need.

Original comment by bjohnson...@gmail.com on 24 Feb 2011 at 6:43

Attachments:

GoogleCodeExporter commented 8 years ago
6 seconds for 100 nodes is way too slow, of course :-(
Firebug has a [Profile]-Button in the Console tab (see the my second 
screenshot).
That could help to identify the cause.

You could also try to run this sample locally from the distribution, to see if 
it makes a difference.

Original comment by moo...@wwwendt.de on 25 Feb 2011 at 6:51

Attachments:

GoogleCodeExporter commented 8 years ago
I pressed [Profile], then expanded 'Add 100 nodes(flat)', then [Profile] 
again...

Original comment by moo...@wwwendt.de on 25 Feb 2011 at 6:53

GoogleCodeExporter commented 8 years ago
Please try the Add 100 nodes (flat, force update).

Here is updated profile screen.

Original comment by bjohnson...@gmail.com on 25 Feb 2011 at 3:32

Attachments:

GoogleCodeExporter commented 8 years ago
I would expect 'Add 100 nodes (flat, force update)' to be slow, since it forces 
a redraw after every single node. I get similar numbers here.
Maybe that could be improved, but normally loading is wrapped inside 
`enableUpdate(false/true)` calls. For example, when loading JSON.

Are the other modes reasonably fast on your box? I got 0.167s for '100 Nodes 
flat'.

I would guess, that for some reason your code runs in 'update mode'. Can you 
send a working sample - all files - so that I cun run it and have a look...

Original comment by moo...@wwwendt.de on 25 Feb 2011 at 7:01

GoogleCodeExporter commented 8 years ago
Here is the script I am using.  The url parameter simply points to a URL which 
returns the JSON code I posted in my first post.

<script type="text/javascript">
$(function(){
    $("#location_tree_container").dynatree({
        checkbox: true,
        selectMode: 1,
        classNames: {checkbox: "dynatree-radio"},
        initAjax: {
            type: "GET",
            url: "",
            data: { type: "location_tree" }
        },

        debugLevel: 2,
        onActivate: function(node) {
            $("#echoActive").text(node.data.title);
        },
        onDeactivate: function(node) {
            $("#echoActive").text("-");
        }
    });
});
</script>

Original comment by bjohnson...@gmail.com on 25 Feb 2011 at 7:07

GoogleCodeExporter commented 8 years ago
The other ones are slow on your example as well.  Here is the 1000 flat update.

Original comment by bjohnson...@gmail.com on 25 Feb 2011 at 7:09

Attachments:

GoogleCodeExporter commented 8 years ago
My benchmarks for '1000 flat':

Original comment by moo...@wwwendt.de on 26 Feb 2011 at 8:08

Attachments:

GoogleCodeExporter commented 8 years ago
Hm, I guess I am not sure what to say.  Unfortunately it doesn't work that fast 
for us as you can see from the screenshots.  I checked with 3 of my peers and 2 
said it is slow and they get the same speeds as me, the other one gets the 
speed you do.  You have a great plugin here but unfortunately if it is slow for 
50% of the people viewing the tree I don't think it will work.

Original comment by bjohnson...@gmail.com on 26 Feb 2011 at 4:04

GoogleCodeExporter commented 8 years ago
I would really like to understand what is going on there, but I understand your 
point of course.
(Are RAM, Firefox Version and installed Plugins similar with your peers?)

Original comment by moo...@wwwendt.de on 26 Feb 2011 at 7:15

GoogleCodeExporter commented 8 years ago
I disabled all plugins and extensions in firefox except firebug to test if this 
was the issue and this did not help.

I have 6GB ram and i7 2.67 processor so this shouldn't be an issue.

Is there any other tool I can use to give you further information?  The other 
user that had the issue was using windows XP (I am using vista) and it was same 
version of firefox (latest).

Original comment by bjohnson...@gmail.com on 26 Feb 2011 at 8:13

GoogleCodeExporter commented 8 years ago
Thanks for your support!
Tried on a Windows 7 laptop, FF 3.6.13, 3GB, 2.56 dual core and it's fast.

I guess I have to check some more systems here until I find one that shows the 
slow performance, so I can debug it.

Original comment by moo...@wwwendt.de on 27 Feb 2011 at 8:21

GoogleCodeExporter commented 8 years ago
Ubuntu 10 laptop, FF3.6.13, 1.8GHz dual core, 1GB RAM
takes 1.5 sec (i.e. fast)

Original comment by moo...@wwwendt.de on 27 Feb 2011 at 8:53

GoogleCodeExporter commented 8 years ago
Win XP SP 3, 1 GB RAM, Athlon 3600, FF3.6.13
1.1 sec (fast)

Original comment by moo...@wwwendt.de on 27 Feb 2011 at 9:19

GoogleCodeExporter commented 8 years ago

Original comment by moo...@wwwendt.de on 27 Feb 2011 at 9:20

GoogleCodeExporter commented 8 years ago
Hmm.  Wish there was a way to reproduce this for you.  Are there any other 
tools we can use to help?

Original comment by bjohnson...@gmail.com on 27 Feb 2011 at 4:26

GoogleCodeExporter commented 8 years ago
I am not aware of other tools we could use.
I can try some other boxes in the next few days.

Looking at your results, I see that the min., max., and average timings of 
render() have a huge variant!
Render is called 2008 times, taking 8034 ms. altogether. But the max. exec time 
of a single call is 7841. 
My guess is, that there is one single command that introduces the delay (or is 
slow when called for the first time)

If I could get my hands on a slow system, I would add some debug-logging to the 
render() code, to see some more time stamps and step through it with firebug.
A 7-second delay should be noticable...

Original comment by moo...@wwwendt.de on 27 Feb 2011 at 6:50

GoogleCodeExporter commented 8 years ago
If you want to add more debug code I can do more testing in firebug and send 
any results if needed.

Original comment by bjohnson...@gmail.com on 27 Feb 2011 at 6:52

GoogleCodeExporter commented 8 years ago
The first thing would be to uncomment this
//      this.tree.logDebug("%s.render(%s)", this, useEffects);
in render() around line 265.

If it turns out, that the first call to render is the slow one, then you can 
set a breakpoint there and [F10] away.

Original comment by moo...@wwwendt.de on 27 Feb 2011 at 7:08

GoogleCodeExporter commented 8 years ago
Can you do that on your example or do you mean in our code?

Original comment by bjohnson...@gmail.com on 27 Feb 2011 at 9:37

GoogleCodeExporter commented 8 years ago
sorry, I meant 
- extract dynatree-1.1.0.zip from the download page
- patch src/jquery.dynatree.js
- open and debug doc/test-bench.html
(assuming the problem occurs, when running locally)

Original comment by moo...@wwwendt.de on 28 Feb 2011 at 6:31

GoogleCodeExporter commented 8 years ago
I found one unnessecary call to render(), that I removed. So test-bench.html 
should run faster in v1.1.1.
Still doesn't explain the differnece though.

Original comment by moo...@wwwendt.de on 28 Feb 2011 at 8:31

GoogleCodeExporter commented 8 years ago
Still seems to be slow.  Have not had a chance to add your debugging code.  
Will try to do it this week.

Original comment by bjohnson...@gmail.com on 2 Mar 2011 at 12:43

GoogleCodeExporter commented 8 years ago
Just released 1.1.1 one minute ago. 
render() is now only called 1007 times in the 'Add 1000 nodes (flat)' sample. 
here, (was >2000 times).
But this might only apply to the special benchmark sample, not your real-world 
scenario.
My guess from comment 23 may also point in the wrong direction, because the 
first call to render contains all other recursive calls to render, ehich 
explains that it takes the longest time.

Original comment by moo...@wwwendt.de on 2 Mar 2011 at 6:47

GoogleCodeExporter commented 8 years ago
Martin,

Don't know if you know this site, but maybe it can help in some way:

http://jsperf.com/

Yomodo

Original comment by prana001 on 10 Mar 2011 at 11:36

GoogleCodeExporter commented 8 years ago
I think we are getting a little better performance with firefox 4 but I wanted 
to check, has anything been updated since I last posted?

Original comment by bjohn...@accomplishhosting.com on 29 Mar 2011 at 1:04

GoogleCodeExporter commented 8 years ago
Only the changes mentioned in comment 30... I guess you have tried with 1.1.1?
I wasn't able to reproduce the slow behavior so far, may be I should add a 
feedback link to the benchmark page...

Original comment by moo...@wwwendt.de on 29 Mar 2011 at 5:46

GoogleCodeExporter commented 8 years ago
Just tried with FF 3.6.16 on Ubuntu inside a VirtualBox(!): 'Add 1000 nodes 
(flat)' took around 1 sec.

Original comment by moo...@wwwendt.de on 29 Mar 2011 at 6:04

GoogleCodeExporter commented 8 years ago

Original comment by moo...@wwwendt.de on 6 Oct 2013 at 3:16

GoogleCodeExporter commented 8 years ago
Cleanup Scrumboard

Original comment by moo...@wwwendt.de on 2 May 2014 at 7:47