| Issue 178: | speed up event rendering | |
| 9 people starred this issue and may be notified of changes. | Back to list |
when 20+ events get on the screen, takes a while. should optimize
Nov 26, 2009
#1
augusto_...@gmx.de
Nov 26, 2009
Hello Adam, the problem is the rendering, for 80 events take 8 seconds. How can i optimize? best regards
Dec 22, 2009
i'm going to devote 1.4.4 entirely to optimizing event rendering (in both agenda and basic views). i have a few ideas.
Summary:
speed up event rendering
Dec 22, 2009
Issue 254 has been merged into this issue.
Jan 13, 2010
AWESOME! thanks Adam. Is there a possibility of you releasing your 'working' version of your work during the process? I know I'd love to help out.
Jan 13, 2010
I think 1.4.3 (jquery caching) helped a bit and thank you Adam for the great work you have put into full calendar.
Jan 21, 2010
Hi, I read that the addEventSource method can improve rendering because the calendar object is not rendered for any event. I try to use it (the json return the event) but they are not rendered on calendar. Can be the AddEventSource a trick to speed up rendering of many events?When do you suppose version 1.4.4 will be available? BR, Enrico
Jan 21, 2010
Hi, I try now also the addEventSource successfully. Unfortunately the render is slow when events are a lot (>50). I can hae up to 10 events for day..this means up to 10*30=300 events in month view.....this mean that month view rendering now is very very slow. There will be soon a solution to this problem? BR, Enrico
Jan 22, 2010
I built a calendar using jQuery not too long ago, and made a spreadsheet with some techniques I used to improve the performance. In case it's helpful, you may want to check it out. As you'll see, the most dramatic improvements were achieved by creating DOM elements using string arrays instead of jQuery objects. http://bit.ly/6IxINa Michael
Jan 22, 2010
Michael, Thanks for sharing the spreadsheet. Is your calendar up anywhere, would love to see and compare. Your suggestions align perfectly when what I've experienced as well. Thanks for the post, look forward to a URL of your demo! Travis
Jan 22, 2010
Sure thing -- I believe it defaults to "List view", and the link to "Calendar view" is on the right side above the months. That said, the same performance techniques would apply to either case (list view or calendar view). http://livekick.com/yourconcerts Michael
Jan 22, 2010
Michael, your calendar looks great! Thanks for the URL. Site looks good overall as well. Hopefully, we can improve the rendering time here. I was searching the web today, and found Web2Cal and the event rendering/processing is extremely quick. But aside from the price, I don't like the footprint/closed source etc. Love the UI of FullCalendar way better. http://www.web2cal.com/web-2-events-calendar/web-2-calendar-demo.html
Jan 22, 2010
Thanks very much, Travis -- lots of work went into that; I wish I had found fullcalendar first ;) Web2Cal is appealing, especially since it'll feature an iPhone interface. But yes; the price is steep and the UI isn't as nice.
Jan 23, 2010
Hello everyone, thanks for your concerns, sorry i haven't been actively involved in this discussion, been pretty busy. I'll get to work on this issue this weekend and hopefully have a release by mon/tues/wed. i was able to start on this a few weeks ago, you can see my progress here: http://github.com/arshaw/fullcalendar/tree/v1.4-speedup here are the ways i have been optimizing - making a giant html string for all events and inserting it all at once (as opposed to incrementally creating each div) - grouping all my width()/height() queries when positioning events. these all lead to offsetWidth/offsetHeight, which seem to force internal browser rerenders, so don't want to mix getting and setting these widths b/c leads to quadratic event rendering. - lazily attaching click/draggable/resizable on mouseover these seem to work really well. in my tests they've been cutting down on rendering time 70%+ will keep you updated
Jan 23, 2010
Nice, Adam -- thanks for the info. Michael
Jan 23, 2010
Thanks Adam, your work is much appreciated!
Jan 25, 2010
Hi Adam,
thank you for your work.
I tested v1.4-speedUp. I note performance are better but yet I have poor performance
on my application.
This is what I achieve:
- month view (about 700 events): about 40 sec for rendering
- week view (about 200 events): about 7 secs for rendering
- day view (20 events): less than 1 sec
Moreover, if I switch views (from day to week to month, then from month to week to
day etc....) the previous elapesd time grow up...for example the week view takes
about 15 seconds.
Note that every time I change view, I have to remove and reload events from my
back-end (ajax call to my back-end) so I use the following code:
$('#calendar').fullCalendar('removeEvents');
.......
......
ajax call....and if success I use the json response to add events:
$("#calendar").fullCalendar("addEventSource",msg.items);
My question is:
- I am using in a no good way the fullcalendar?
Take in mind that I need to remove and then reload events every time I chaneg view
bacause I am using fullcalendar to "share" more calendars..so i can filter events for
more than on users and show events of more than one user at the same time on the same
calendar (like google calendar). So an user can choice to show only his/her events or
also events of other users (if he/she has rights). So, he selects events to show from
a list of users (calendars) and from a view to another he could have changed this
set...so I need to remove all events and reload all events of the users (calendars)
he has selected.
I think it is hard to get the same behaviour all in js. I have impleted this on the
backend (the backend return only the events for the selected users on the current
view) and the backend performance are good. The performance is poor on the js
side..when remove and add the new source.
BR,
Enrico
I put some timestamp in my code in order to check what is the operatio
Jan 25, 2010
what browser are you using? what is your machine like (processor, memory)? also, did you check out the latest commit of the speedup code? i will look into it...
Jan 25, 2010
enrico, can you also show me your html/js code, so i can look into your add/removeEvents situation? can you also post a text file with the json for the events you are using? either post here or send to arshaw a arshaw.com. thanks a lot adam
Jan 25, 2010
Hi Adam,
in my code I have a renderEventsInView js function that is called every time there is
a switch among views (month, agendaWeek and agendaDay) or when something else happen
(for example I select waht "kind" of events I want to view from an my external list).
This function is very simple (I remove from here some line of code that is not useful
to our goal):
function renderEventsInView(viewstart,viewend,viewname,typeObj, array){
//first remove all events
$('#calendar').fullCalendar('removeEvents');
//now get events from backend on the current view
//HERE THERE IS MY AJAX CALL THAT RETURN A JSON..SEE LATER
$.ajax({
type: "GET",
url: "....",
data: mydata,
dataType: "jsonp",
success: function(msg){
//add the event source (jsonp items array)
$("#calendar").fullCalendar("addEventSource",msg.items);
error: function(msg){
alert( "Error: " + msg.code );
}
});
}
The JSON returned message (for month view about 700 events) is the attached file(take
in mind I have filled my backed database with some event test).
Jan 25, 2010
Enrico, I have tested both your described setup (with renderEventsInView) and a simplified setup (using a straight json feed http://arshaw.com/fullcalendar/docs/event_data/events_json_feed/) the simplified setup performs pretty well IE6 ~ 10 seconds (could still use work :( ) IE7 ~ 6 seconds IE8 ~ 3 seconds FF ~ 2 seconds Chrome ~ 1 second again, what browser are you using? i have attached a copy of all the code i am running. run tests/many_events2.html in your described setup i'm wondering if you are calling renderEventsInView from within viewDisplay. if so, rendering would happen twice. once on the cached events before viewDisplay is triggered, and once in renderEventsInView. would describe why your described setup is taking twice as long for me. though i'm not sure exactly what your setup is, i would recommend using an events function (http://arshaw.com/fullcalendar/docs/event_data/events_function/). can you please run the simplified version (tests/many_events2.html as is) and let me know what the performance is like?
Jan 29, 2010
Thank you adam for your work and help.
Sorry for my late to reply, but I was away.
I use Firefox, but I also tested on other browser (IE and Chrome).
I note my error in code and now I am able to manage about 200 events (in month view)
quickly (IE takes about 2 seconds...but Firefox and Chrome are really more efficient).
As you said, I call renderEventsinView from viewDisplay. Ok, I can use events
function when I move from one view to another. Anyyway, I need to control also the
events to show on calendar from "outside" the calendar triggered events and so I need
to mantain the rederEvetnsInView function (triggered by my action to for example
choose a type of events or event owner to show on the calendar from a lst of event
type or evetn owner that I define).
I mean, I need to trigger the refresh of events not only from your triggered events
but also from mine trigger. So my question is:
- in this case the best way is to remove all events and then add a new source?
$('#calendar').fullCalendar('removeEvents');
.....
$("#calendar").fullCalendar("addEventSource",msg.items);
BR,
Enrico
Jan 30, 2010
Hey Adam, was wondering if you planned on 'officially' releasing the code you've been working on for 1.4.4 soon? Thanks so much for all your work. Travis
Jan 31, 2010
enrico, it sounds like you could use the refetchEvents method (http://arshaw.com/fullcalendar/docs/event_data/refetchEvents/) traviscooper, i was hoping to release 1.4.4 last week, but i found some of my changes caused bugs. also, the agenda view optimizations were not where i wanted them to be, and neither were the basic views in IE6. however, i've been working over the past couple of days and these problems are solved. also, i was able to halve the event rendering times i previously reported. i've tested it quite a bit, but not enough to call it a release yet. hope to do a full QA early this week. until then, i can post 1.4.4 "beta" on this thread. please try it out and test it a bit if you'd like. thanks, adam
Feb 2, 2010
Could you please give us a changelog for this beta version? ;)
Feb 3, 2010
i just officially release 1.4.4 (arshaw.com/fullcalendar/download) this released only dealt with raw speed of rendering of large lists of events, and i was pretty happy with the performance gains. more optimization could be done in other areas however, such as only rendering certain events on re-renders, as well as improving memory usage/leaks. but the changes in 1.4.4 should satisfy most people for a while. if you have any other ideas for optimizations, please enter them as new issues. also, if you find bugs you think might be a result of the optimizations, please enter those as new issues also. thanks, adam
Status:
Fixed
Feb 4, 2010
Trying it, thanks
Aug 13, 2013
(No comment was entered for this change.)
Status:
Implemented
Aug 13, 2013
(No comment was entered for this change.)
Status:
Released
|
|
| ► Sign in to add a comment |