You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Justin Mclean <ju...@classsoftware.com> on 2017/10/29 09:33:58 UTC
Re: [royale-asjs] branch develop updated: Better date comparisons
Closes #55
Hi,
Could you check the performance of this.
Changing the code to use date strings ands call toDateString 40+ times with a similar number of string comparisons is likely to be a lot slower than simple month and day numeric comparisons.
Thanks,
Justin
Re: [royale-asjs] branch develop updated: Better date comparisons
Closes #55
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> What is the point of fighting on probably fraction of performance here?
Because it’s just as easy to not have that performance penalty and then their’s no need to worry about it.
As only one month is displayed at once it would be far better to change the code to what’s below (not tested) and only check the year and month once.
public function getIndexForSelectedDate():Number
{
var d:Date = _selectedDate;
if (d == null || _days[0].getFullYear() != d.getFullYear() || _days[0].getMonth() == d.getMonth()) return -1;
for(var i:int=0; i < _days.length; i++) {
var test:Date = _days[i] as Date;
if (test != null) {
if (test.getDate() == d.getDate())
return i;
}
}
return -1;
}
The _days.length shouldn't be calculated every time around the loop either but that was raised in another pull request.
Thanks,
Justin
Re: [royale-asjs] branch develop updated: Better date comparisons
Closes #55
Posted by Piotr Zarzycki <pi...@gmail.com>.
Hi,
The question is how much are you using that method with such comparision?
Does user will experience slowing down clicking something?
What is the point of fighting on probably fraction of performance here?
Piotr
On Sun, Oct 29, 2017, 10:34 Justin Mclean <ju...@classsoftware.com> wrote:
> Hi,
>
> Could you check the performance of this.
>
> Changing the code to use date strings ands call toDateString 40+ times
> with a similar number of string comparisons is likely to be a lot slower
> than simple month and day numeric comparisons.
>
> Thanks,
> Justin