| Issue 2259: | Performance decrease in 2.x |
1 of 2569
Next ›
|
| 14 people starred this issue and may be notified of changes. | Back to list |
The following jsFiddles use the same code, only switching from 2.0.0 to 2.1.0 versions of FullCalendar. On a Core i7 FireFox the 2.0.0 versions loads 1500 events in under a second, the 2.1.0 version takes 3 - 4 seconds. Also the removeEventSource is extremely slow. 2.0.0 - http://jsfiddle.net/indexic/u6youn1b/ 2.1.0 - http://jsfiddle.net/indexic/L9z2Lbur/
Aug 27, 2014
Here are my findings executing on FF on my machine: WITH JSFIDDLE ------------ 2.0.0 Milliseconds to setup: 1047 Remove source: 21 Add source: 872 2.1.0 Milliseconds to setup: 1866 Remove source: 1870 Add source: 3403 ON A STANDALONE TEST PAGE -------------------------- 2.0.0 Milliseconds to setup: 949 Remove source: 21 Add source: 766 2.1.0 Milliseconds to setup: 1503 Remove source: 262 Add source: 1427
Aug 27, 2014
SUMMARY: 1) event rendering upon initialization went x2 2) removeEventSource went x100 !!! (only x5 on Google Chrome though) 3) addEventSource went x2 fixing removeEventSource takes priority here. thanks for your report.
Summary:
Performance decrease 2.1.0, especially removeEventSource
(was: Performace problems with 2.1.0 - 3 to 4 times slower than 2.0.0)
Status: Accepted
Aug 27, 2014
NOTE: the x100 increase happens only inside the JSFiddle for some reason. Otherwise it's a x10. We're talking FF here. Still a problem.
Sep 27, 2014
I've noticed a significant decrease in rendering speed as well, didn't realize it was going from 2.0 to 2.1, as I jumped straight from 1.6.4. Here are my numbers for 1.6.4 - http://jsfiddle.net/andrewswihart/q0efd9uq/ Milliseconds to setup: 439 Remove source: 26 Add source: 230 ...and on 2.1.0 - http://jsfiddle.net/indexic/L9z2Lbur/ Milliseconds to setup: 2635 Remove source: 2067 Add source: 4264 So, from 1.6.4 to 2.1, there is ~6x, 80x, and 18x increases. Even 2.0 is quite slow compared to 1.x. Is there any hope for optimizing 2.x to anywhere near the speed of 1.x? I love the show more events pop-up and use of moment.js, but the speed degradation is a big downside. Even with just one event each day, the snappy month switching of 1.6.4 is gone.
Oct 16, 2014
I render a lot events. The rendering speed during initialization is okay for me. But when I call renderEvent for a collectin of objects I retrieve from a server it is very and very slow.
Oct 26, 2014
Honestly, 2.1 shouldn't be used in production. There is some extremely inefficient looping going on for every single event rendered. Other than that, it's working well... but this thing is a browser killer. Anybody who has a decent number of events on their calendar(s) will surely try to refresh the browser or assume it has frozen and close it when switching dates/initial load/etc. It's been 2 months since this performance issue was posted here and there has been no visible progress made so I'm guessing it isn't a quick fix. Just when things seemed to be rolling!
Oct 28, 2014
If anybody was curious, on a stand-alone test page with 250 events from 10 event sources, there is over a 1000% reduction in event rendering speed with 2.1.x vs. 1.6.4; changing views can take up to 10 seconds to complete. It's bad enough as it is but even worse when pulling from multiple sources. There is a massive spike in garbage collection with 2.1.x and it's simply unusable for anything more than a few dozen events from a single calendar source. We have spent hours combing through the code but, in an effort to reduce the file size (which is great) there was a ton of reused code that makes troubleshooting a nightmare. My guess is this amicable effort in file size reduction is also partly to blame for the poor performance. It's been over 2 months since Adam posted in this topic - any idea if he's still around?
Oct 30, 2014
I have a small project I manage and used to be able to display all events for all ~30 event sources in less than 3 seconds on 1.6.4. With 2.1.1 it sits there for about 45 seconds and then crashes the browser on every machine I've tried it on. A lot of work went into this and I think when the performance issues were brought to the dev's attention it took the wind out of his sails. As the above mentioned, he hasn't even bothered to post a progress update in here in 2 months. I spent about 5 hours trying to optimize the code and it shaved off about 20% of the rendering time but it's still unacceptable. I just don't see too many other areas that could be optimized. No idea what happened here! A mess for sure and it's too bad as this was a great project and nobody can use it.
Oct 30, 2014
OK, I think we've established that it's a bummer that performance went down. Let's express a little more thanks to Adam for making his amazing work free for us to use. I'm sure Adam has a life beyond FullCalendar. It may be another year or who knows, tomorrow, but I believe Adam or someone else will eventually tackle the performance issues. I am personally using 2.1 rather than 1.6.4, as the many, many improvements are worth it for me. My project has hundreds of events each month, but I use filters to give users selective control to display a small fraction of events. It is definitely usable, if a tad sluggish, when you keep the event count to just a few per day. I've also added a mini calendar (pikaday) similar to that in the left column of Google Calendar to more quickly navigate between distant months so you don't have to just rely on clicking the next / prev buttons over and over to get around. If anyone has constructive information where they've found places in the code to optimize, let's talk about that here.
Oct 30, 2014
when i looked into this a while back, with some cursory profiling, the problem seemed to be more related to creating many intermediate Moment objects when doing event slicing. So I either need to find a way to make the creating of moments more efficient, or avoid using moments alltogether. Either approach will take quite a bit more time to investigate / patch.
Nov 2, 2014
I'm beyond thankful for all of the hard work that has gone into this project - it's hands-down the most complete/universal calendar option. I just wish I could take advantage of some of the more recent hard work instead of continuing to use a version that's over a year old. If there are more than a dozen calendar sources with a handful of events on each it literally crashes most browsers. It takes even less than that to kill the browser on iPads/etc. 1.6.4 was lightning fast. I was just concerned because there are certain features in 2+ we need... and I hadn't heard from Adam on this issue in a couple months. Also, there were only 7 stars on this issue and he usually places a lot of importance on the number of stars - most people with a single calendar source and a few events don't realize what a huge performance decrease this is. We're talking up to 50x slower in real-world situations and completely unusable in more extreme cases. For whatever reason, multiple sources seem to hit it a lot harder than just a lot of events on a single source (although that's a lot slower too). Just saying, the latest release that should be used in production remains 1.6.4. Hopefully we get past this issue and I understand all of the hard work and the commitment required here - pretty thankless stuff. Just wanted to ensure people realized this needs to be the absolute top priority for the next release! Thanks, Adam.
Nov 2, 2014
I wonder if this will help the Moment.js issue: https://github.com/moment/moment/issues/1754
Nov 9, 2014
The 2.1 code has changed so drastically that it's difficult to pinpoint all of the areas contributing to this issue. As we're 2 1/2 months into this issue (and we have spend a lot of time in the 2.1 code), we have decided the best bet (for us) is to throw out the 2.1 code completely, fork the last production-ready version (1.6.4) and systematically implement features/fixes while continuing to test performance at each step. Moment appears to be partially to blame but certainly does not contribute to the bulk of the performance hit (in our tests thus far). Once we have made some progress worth sharing, we'll get as many people involved as possible to attempt to finalize this thing. Obviously, for people with only a single calendar and a handful of events 2.1 remains a solid solution. We just cannot justify spending any additional time in the 2.1 code when it's possible there's no way we can ever get anywhere near 1.6.4 performance. Hopefully Adam is still working on 2.1 as well so eventually there will be a number of options. For us, performance will be a big priority so there may be certain features we cut (or at least enable the option to enable/disable) to avoid issues.
Nov 14, 2014
Maybe I'm missing something, but after looking closer at the two Fiddles above the 2.1.0 version (poor performance) seems to be rendering twice as many events (each event is duplicated) versus the 2.0.0 fiddle which seems faster, but correctly loads each event only once. Just mentioning since it took me a few minutes to notice the difference, and could that be the real reason for the performance degradation, at least with the Fiddles above?
Nov 14, 2014
I just release v2.2. I optimized moment-creation. Makes things a lot faster. Things are about twice as slow as 1.x still though. But an improvement over the previous 2.x, which was many more times slower. The remaining performance problems seem mainly due to page reflows which are difficult to prevent. For example, one is needed to detect and adjust scrollbars for the default height settings. If you don't need scrollbars, set `height` to 'auto' and you should see a performance boost. http://fullcalendar.io/docs/display/height/ The performance decrease specifically related to removeEventSource is caused because of this same scrollbar reflow issue. Like the other reflow issues, it is an overhead cost and does not seem to scale in time by the number of events (so it is not O(x), it is constant time, I think). So, I will rename this issue to reflect. I will still keep this issue open for investigating other performance improvements. @mhomme, I'll have to investigate your claim, but I have a feeling event rendering is happening twice because a window resize is being triggered as a result of the events rendering large. Maybe it only happens in the JSFiddle environment (since the code execution window is small). But have to investigate. Please give 2.2 a try a tell us about your results.
Summary:
Performance decrease in 2.x
(was: Performance decrease 2.1.0, especially removeEventSource)
Nov 25, 2014
Everyone was freaking out about these performance problems a few weeks ago, and now that it's fixed, silence? Can anyone report any results?
Nov 25, 2014
Adam: Really appreciate the update and I apologize for, at the very least, my silence. Due to the performance drop, we were already quite deep into overhauling 1.6.4 and it's currently fulfilling our needs, fortunately. 2.2 is an improvement over 2.1 in the speed department, no doubt, but still suffers heavy slowdowns when dealing with larger numbers of events and/or sources. For example, 10 sources with 20 events each (200 total events) takes ~0.4 seconds on 1.6.4 and ~5.5 seconds on 2.2. While for most applications this might not be overly significant... it just results in a sluggish feel for anything in production. Also, on some older/slower machines, it is still crashing browsers. I would say 2.2 is suitable for production when using a single event source (or, if more than that, no more than a handful of events each) but anything that needs to scale will run into a bottleneck. I've been meaning to write back but it's been a crazy couple weeks and I've managed for get 1.6.4 beefed up enough for our current needs. I am surprised to see no responses here! Basically, we decided that anything more than a 50% decrease in speed is too big of a hit and I just don't see any way we can get close to the speed of 1.6.x here - there is more happening, obviously, and it just takes longer to get to the finish line. Performance is just such a priority for most applications, unfortunately. I even tried offloading some of the work server-side and delivering the events preassembled to render - even our servers were taking a beating. Perhaps the solution here is maintaining one version for speed and the other for features until this case can be cracked. I've spent a lot of time in the 2.1 code (not so much in 2.2) and I've tried almost everything I could think of with minimal success. It's probably my fast enough for the majority of use-cases I would imagine and for the most part 2.2 is a significant upgrade from 1.6.4. We wish we could use it!
Nov 25, 2014
You tried v2.2 and it still take over 5 seconds? While 1.6.4 takes less than a second? I did not realize you were dealing with multiple event sources. Depending on how you're using it, it will affect performance characteristics in different ways. Are you calling `addEventSource` in quick succession? If so, Issue 2344 is trying to address that exact problem. Anyway, if you decide to upgrade to 2.2 or above, please post any benchmarks here. Until then, cheers.
Dec 2, 2014
Adam: Sorry for the delayed response (again) - was out of town for the holidays and had some weather-related travel difficulties that jammed me up. Yes - we are calling "addEventSource" in quick succession - the performance hit is definitely present even with a single source but, as I said, it's amplified considerably when using multiple sources. I will look into the issue you referenced and determine if I can shave more time off the rendering. I would love to upgrade to 2.2+ and, in fact, we had it in production briefly until our users started reporting issues (browsers freezing/etc) - certainly would like to help out in any way possible and we will get you some benchmarks when we can (we have a development server running the latest version of fullcalendar). We are pulling in an array of events with a single AJAX request and then looping through the array and adding the event sources to the calendar. This worked great in all versions < 2.0. We also have a socket.io server implemented in a similar fashion - some of our users have over 50 calendars so instead of opening up 50+ socket.io connections consolidate it down to a few (sometimes as few as one if the amount of data per source is minimal - it's all load-balanced). Again, this all worked well in all versions < 2.0. I understand that our implementation isn't going to be very common and wouldn't expect you to dismantle what you've built for fringe use-cases. The latest release is definitely an improvement over when this issue was initially reported and, as I said, it is probably production-ready for most uses. We would have it in production ourselves if we could figure out a way to avoid these massive, seemingly exponential performance hits when used with multiple event sources. When we had 2.1 in production, it was actually crashing some browsers even with a single event source (if they had enough events loading in). We seem to be some of the only people overly concerned with this issue (at least publicly) and, as I said, our (slightly) modified version of 1.6.4 is getting the job done for now. If you have other priorities, we certainly understand. At the same time, we would be happy with work with you on getting this resolved as much as possible. Thanks for all you do - don't think we don't appreciate it! We love the direction you are going with fullcalendar and it's great to see the project is still active after all these years - we just hope we can eventually make the latest and greatest work for our purposes. If you have suggestions on better ways to handle the event sources, we're all ears - the only requirement we have is to obviously limit the number of AJAX requests and/or socket.io connections - if we can bring all of the data in with a single request, as we are now, and parse it in a better way that will eliminate the bottleneck we'd be happy to make the adjustment.
Dec 30, 2014
We are facing the same problem as mentioned in this ticket and https://code.google.com/p/fullcalendar/issues/detail?id=2344 using 2.2.3. We are also working with multiple eventSources, removing and adding those as needed (looping). I took a look at it with the profiler and it would seem that a) removeEventSource is heavier than adding one for some reason b) the issue could probably be helped via some way to do these changes in a batch without a rerender being executed between each remove / addition. For our use case it would be best to have a way to both add and remove event sources simultaneously before executing a rerender. Adam: I saw you were asking for feedback from 2.1 to 2.2: I can confirm that the 2.2 helped with this (I don't have any numbers to give, but I could notice that upgrading made changing the sources snappier). Even so, the problem is still pretty visible when multiple event sources are removed at the same time. For what it's worth: We haven't noticed / gotten reports of any freezes mentioned previously.
Jan 19, 2015
Has there been any progress made here? Just curious how far down the list of priorities this is as v2.2.6 appears on par with 2.2 (an improvement from 2.1, but still considerably slower than 1.6.x, and exponentially slower when dealing with multiple event sources). We have deconstructed and reconstructed the entire code and could not pinpoint any single area as the primary culprit. We managed to trim a bit of time off here/there but it was at the expense of code size and, even then, not enough to improve performance to production eligibility. This has all certainly given me a new appreciation for the impressive performance of the old 1.6.x code. We continue to build relevant features/fixes into the old code but it is becoming more and more complicated. Thanks for the continued effort, Adam. Always blown away by your dedication - you are in rare company.
Feb 9, 2015
@bholzer, I'm elbow deep in some other projects so haven't had time to investigate further. The rendering slowness in 2.x is almost definitely caused by page reflows. Please disable height to 'auto' as described in comment #16 and monkey patch the multiple-event-resources rendering slowness by introducing a setTimeout (as described https://code.google.com/p/fullcalendar/issues/detail?id=2344#c1) and then have one of your developers report back with the results.
May 26, 2015
Issue 2495 has been merged into this issue.
May 26, 2015
Adam: I haven't commented on this in a while as I know you are working on other portions of Fullcalendar... but just wanted to note that, while this performance decrease remains significant when working with multiple event sources in the manner we were, it is much less of an issue when rendering everything at once and simply using classes to show/hide events as toggled (instead of actually removing/adding the event sources on command). Outside of older/slower computers or poor connections and what may be perceived as slightly clunkier on initial pageloads (since we load in everything initially even if toggled off... to avoid issues when toggling sources on). We have come to the conclusion that we will be able to make this work... and we will focus more effort on better ways to provide additional options to our users for organizing/grouping calendars. To summarize, this performance decrease is not the deal-breaker it was 5 months ago for us - if anything, it has pushed us to improve our own system and user interface. Obviously any performance improvements are a big plus but we are just happy to see continued activity on this project.
Aug 21, 2015
Discussion for this issue has moved to the following URL: https://github.com/fullcalendar/fullcalendar/issues/2524 This is because Google Code is shutting down. Apologies if you are being pestered with these notifications. This is a one-time event. Happy coding, Adam
Status:
ExportedToGithub
|
|
| ► Sign in to add a comment |
Labels: Type-Bug