Bugzilla

(In reply to Paul Morris [:pmorris] from comment #75)
> (In reply to Richard Leger from comment #67)

> I haven't had time to look into this further this week, but rest assured that we do want to improve the slower performance you're seeing.  

Thank you for acknowledging and looking into it... it keeps me motivated :-)

> We are just spread too thin to get to everything as quickly as we'd like.

Understandable... but this situation is not new nor it is gonna change anytime soon... while performance issues have been going on for years... 
So at what point do you think the performance issue(s) would to be tackled, do you reckon? Any time frame in mind? Postponed advitam eternam because of no time? 
Would post 78 ESR be a good time to start tackling performance issues? In a follow up update(s) perhaps or prior the following ESR at the latest?

For the time being, would you think it may be feasible to land a fix for this particular bug in 78.1 or 78.2 update prior everyone auto-update within the ESR channel? 

Long term, do you have plan to automatically measure and test Calendar feature performance as part of your test suite during each development iteration cycle to:
- quickly identify performance regression before they even land in beta
- improve performance over time by measuring progress

Could Telemetry be of help perhaps to measure type of calendar in use, number of items, loading time as a basic start line, then progressively expand depending on options: cache enabled/disabled, filtering options, sorting options, etc...? Maybe starting with cache mode on/off option first... I am saying this because in Bug 1502923 (2 years old - closed 11 months ago) showed that sorting (which is not activated by default) had a tremendous impact on performance (causing calendar to load in 100mn+ instead of 10mn-) at the time... and this is only the tip of the iceberg as you may already know... so it may be essential to automate performance testing... Then you can also measure performance when 1,2,3.... more large calendar are setup and enabled at the same time... to identify scaling perf issues (long term)...

Also DevTools > Networking already is able to record quite some info about network pic (request/response) and possibly delay/gap between them (TB overall processing time)... 

Just some ideas... maybe you are already working on it... but just thought to suggest it...

This way you may be able to get automatically data to evaluate performance issues and bottlenecks without wasting too much time on it? 
My manual testing of performance here is indeed taking tremendous amount of (my) time, but it is necessary to raise awareness in the hope it would be fixed at some point not only this bug but the overall performance of Calendar feature as a whole... 
Automatic measurement and testing may be the key to save time while tackling the perf issues in Calendar feature... or at least integrate them in the current allocated time dev team may have during development iteration(s)...

I was hoping that while integrating Lightning into Core and as part or refactoring, this would have started to happens slowly in parallel to get in a better position now for the ESR and beyond but it hasn't, it seems...

In addition you may be able to get more hands on by considering setting up a Thunderbird Summer of Code program perhaps (as part of the Google Summer Code program or on its own) to bring people on board for a short period of time to work on specific (very) long lasting issues to have them properly analysed to identify possible solutions. Could that help further in any way?

> If you have a chance to upload and share a new profile (using the latest beta) to the profiler.firefox.com site, that would be helpful (now that the fix for that one issue is in).  

My bad I thought I had done so, I may have forgotten to paste the link in the comment at the time...

Attachment 9160700 [details] as per Comment 67 has been uploaded on profiler.firefox.com, here is the link:
https://share.firefox.dev/2NWyEKK

> Also, I think you should be able to debug async functions/code in the debugger, at least it works for me.  Try using the "step in" button rather than the "step over" button, and that should let you step into async function calls (e.g. where there is an "await").  That's worth a try if you haven't tried that yet, and are still motivated.

Believe me I do "step in" but at some point (which I haven't been able to identify) it gets "stuck" and the debugger view does not change as you run or step-in for about ~x30 times then it comes back... and goes again... at some point it also start to Not Responding but I cannot find why nor at what point (line of code), cannot get to it... believe me I tried and I would have shared info if I could... that is why I am seeking your help here :-)

As I said before, if someone want to do a private remote session with me to look at issue first hand, it can be arranged if that can help in any way.

Thank you for your support and making TB better everyday!

Regards,
Richard

(In reply to Paul Morris [:pmorris] from comment #75)
> (In reply to Richard Leger from comment #67)

> I haven't had time to look into this further this week, but rest assured that we do want to improve the slower performance you're seeing.  

Thank you for acknowledging and looking into it... it keeps me motivated :-)

> We are just spread too thin to get to everything as quickly as we'd like.

Understandable... but this situation is not new nor it is gonna change anytime soon... while performance issues have been going on for years... 
So at what point do you think the performance issue(s) would to be tackled, do you reckon? Any time frame in mind? Postponed advitam eternam because of no time? 
Would post 78 ESR be a good time to start tackling performance issues? In a follow up update(s) perhaps or prior the following ESR at the latest?

For the time being, would you think it may be feasible to land a fix for this particular bug in 78.1 or 78.2 update prior everyone auto-update within the ESR channel? 

Long term, do you have plan to automatically measure and test Calendar feature performance as part of your test suite during each development iteration cycle to:
- quickly identify performance regression before they even land in beta
- improve performance over time by measuring progress

Could Telemetry be of help perhaps to measure type of calendar in use, number of items, loading time as a basic start line, then progressively expand depending on options: cache enabled/disabled, filtering options, sorting options, etc...? Maybe starting with cache mode on/off option first... I am saying this because in Bug 1502923 (2 years old - closed 11 months ago) showed that sorting (which is not activated by default) had a tremendous impact on performance (causing calendar to load in 100mn+ instead of 10mn-) at the time... and this is only the tip of the iceberg as you may already know... so it may be essential to automate performance testing... Then you can also measure performance when 1,2,3.... more large calendar are setup and enabled at the same time... to identify scaling perf issues (long term)...

Also DevTools > Networking already is able to record quite some info about network pic (request/response) and possibly delay/gap between them (TB overall processing time)... 

Just some ideas... maybe you are already working on it... but just thought to suggest it...

This way you may be able to get automatically data to evaluate performance issues and bottlenecks without wasting too much time on it? 
My manual testing of performance here is indeed taking tremendous amount of (my) time, but it is necessary to raise awareness in the hope it would be fixed at some point not only this bug but the overall performance of Calendar feature as a whole... 
Automatic measurement and testing may be the key to save time while tackling the perf issues in Calendar feature... or at least integrate them in the current allocated time dev team may have during development iteration(s)...

I was hoping that while integrating Lightning into Core and as part of refactoring, this would have started to happens slowly in parallel to get in a better position now for the ESR and beyond but it hasn't, it seems...

In addition you may be able to get more hands on by considering setting up a Thunderbird Summer of Code program perhaps (as part of the Google Summer Code program or on its own) to bring people on board for a short period of time to work on specific (very) long lasting issues to have them properly analysed to identify possible solutions. Could that help further in any way?

> If you have a chance to upload and share a new profile (using the latest beta) to the profiler.firefox.com site, that would be helpful (now that the fix for that one issue is in).  

My bad I thought I had done so, I may have forgotten to paste the link in the comment at the time...

Attachment 9160700 [details] as per Comment 67 has been uploaded on profiler.firefox.com, here is the link:
https://share.firefox.dev/2NWyEKK

> Also, I think you should be able to debug async functions/code in the debugger, at least it works for me.  Try using the "step in" button rather than the "step over" button, and that should let you step into async function calls (e.g. where there is an "await").  That's worth a try if you haven't tried that yet, and are still motivated.

Believe me I do "step in" but at some point (which I haven't been able to identify) it gets "stuck" and the debugger view does not change as you run or step-in for about ~x30 times then it comes back... and goes again... at some point it also start to Not Responding but I cannot find why nor at what point (line of code), cannot get to it... believe me I tried and I would have shared info if I could... that is why I am seeking your help here :-)

As I said before, if someone want to do a private remote session with me to look at issue first hand, it can be arranged if that can help in any way.

Thank you for your support and making TB better everyday!

Regards,
Richard

(In reply to Paul Morris [:pmorris] from comment #75)
> (In reply to Richard Leger from comment #67)

> I haven't had time to look into this further this week, but rest assured that we do want to improve the slower performance you're seeing.  

Thank you for acknowledging and looking into it... it keeps me motivated :-)

> We are just spread too thin to get to everything as quickly as we'd like.

Understandable... but this situation is not new nor it is gonna change anytime soon... while performance issues have been going on for years... 
So at what point do you think the performance issue(s) would to be tackled, do you reckon? Any time frame in mind? Postponed advitam eternam because of no time? 
Would post 78 ESR be a good time to start tackling performance issues? In a follow up update(s) perhaps or prior the following ESR at the latest?

For the time being, would you think it may be feasible to land a fix for this particular bug in 78.1 or 78.2 update prior everyone auto-update within the ESR channel? 

Long term, do you have plan to automatically measure and test Calendar feature performance as part of your test suite during each development iteration cycle to:
- quickly identify performance regression before they even land in beta
- improve performance over time by measuring progress

Could Telemetry be of help perhaps to measure type of calendar in use, number of items, loading time as a basic start line, then progressively expand depending on options: cache enabled/disabled, filtering options, sorting options, etc...? Maybe starting with cache mode on/off option first... I am saying this because in Bug 1502923 (2 years old - closed 11 months ago) showed that sorting (which is not activated by default) had a tremendous impact on performance (causing calendar to load in 100mn+ instead of 10mn-) at the time... and this is only the tip of the iceberg as you may already know... so it may be essential to automate performance testing... Then you can also measure performance when 1,2,3.... more large calendar are setup and enabled at the same time... to identify scaling perf issues (long term)...

Also DevTools > Networking already is able to record quite some info about network pic (request/response) and possibly delay/gap between them (TB overall processing time)... 

Just some ideas... maybe you are already working on it... but just thought to suggest it...

This way you may be able to get automatically data to evaluate performance issues and bottlenecks without wasting too much time on it? 
My manual testing of performance here is indeed taking tremendous amount of (my) time, but it is necessary to raise awareness in the hope it would be fixed at some point not only this bug but the overall performance of Calendar feature as a whole... 
Automatic measurement and testing may be the key to save time while tackling the perf issues in Calendar feature... or at least integrate them in the current allocated time dev team may have during development iteration(s)...

I was hoping that while integrating Lightning into Core and as part of refactoring, this would have started to happen slowly in parallel to get in a better position now for the ESR and beyond but it hasn't, it seems...

In addition you may be able to get more hands on by considering setting up a Thunderbird Summer of Code program perhaps (as part of the Google Summer Code program or on its own) to bring people on board for a short period of time to work on specific (very) long lasting issues to have them properly analysed to identify possible solutions. Could that help further in any way?

> If you have a chance to upload and share a new profile (using the latest beta) to the profiler.firefox.com site, that would be helpful (now that the fix for that one issue is in).  

My bad I thought I had done so, I may have forgotten to paste the link in the comment at the time...

Attachment 9160700 [details] as per Comment 67 has been uploaded on profiler.firefox.com, here is the link:
https://share.firefox.dev/2NWyEKK

> Also, I think you should be able to debug async functions/code in the debugger, at least it works for me.  Try using the "step in" button rather than the "step over" button, and that should let you step into async function calls (e.g. where there is an "await").  That's worth a try if you haven't tried that yet, and are still motivated.

Believe me I do "step in" but at some point (which I haven't been able to identify) it gets "stuck" and the debugger view does not change as you run or step-in for about ~x30 times then it comes back... and goes again... at some point it also start to Not Responding but I cannot find why nor at what point (line of code), cannot get to it... believe me I tried and I would have shared info if I could... that is why I am seeking your help here :-)

As I said before, if someone want to do a private remote session with me to look at issue first hand, it can be arranged if that can help in any way.

Thank you for your support and making TB better everyday!

Regards,
Richard