Open boynet opened 7 years ago
I didn't make any performance testing since I didn't really notice any issues. I believe you that selecting 800 dates (which are all shown at the same time) might hurt performance a lot, but this is honestly not a very common use case. Still, feel free to open PR as better performance is always a good thing to have.
@nazar-pc I am still unfamiliar with the whole code so maybe I will need a hint
I think that the fastest easiest solution would be to catch the results ofis_year_selected
, is_months_selected
and to invalidate the cache on dates changes
1.where is the best place to listen when date as been changes\added\something new happened?
2.what is the purpose of the function in line 463? I think we can give this function a name and split it to multiple tasks? as it look like it doing multiple things(not 100% sure) 60% time get spends in this function
Yes, this is kind of what I thought as well, simple caching will allow us to radically reduce number of calls to those functions.
fill()
call locally in that function (all calendars are rendered inside in for
loop) since nothing will change until we exit itcurrent_month
is used in order to determine and add different class to the days on calendar that do not belong to months being shown (like first and last few days rendered)I didn't dig deeper, will try to do so soon and walk through all open issues as I do from time to time.
when
mode: 'multiple'
and you select large range of dates the more dates selected the bad the performance are.. and the more calendars are the better it getsit can take 1.2 seconds for select to happen when there are 800 dates selected see this screenshot from TimeLine tab![untitled](https://cloud.githubusercontent.com/assets/1615629/22973742/a781f5b4-f387-11e6-905e-6ffef3479048.png)
the main slowdowns are in
is_year_selected
andis_months_selected
and in the function who called them which also get run multiple times they get called multiple times per each click when each iteration can take 10ms on desktop