Closed m-natarajan closed 3 months ago
Triggered auto assignment to @anmurali (Bug
), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.
This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989
Job added to Upwork: https://www.upwork.com/jobs/~0192a06bcd75528339
Triggered auto assignment to Contributor-plus team member for initial proposal review - @eh2077 (External
)
I would like to take on this job
π£ @goldenbear101! π£ Hey, it seems we donβt have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork. Please follow these steps:
Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>
Contributor details Your Expensify account email: irvinwoluchem@gmail.com Upwork Profile Link: https://www.upwork.com/freelancers/~017e81b8541352d771?mp_source=share
β οΈ Missing/invalid email or upwork profile link. Please make sure you add both your Expensify email and Upwork profile link in the format specified.
Contributor details Your Expensify account email: irvinwoluchem@gmail.com Upwork Profile Link: https://www.upwork.com/freelancers/~017e81b8541352d771?mp_source=share
β οΈ Missing/invalid email or upwork profile link. Please make sure you add both your Expensify email and Upwork profile link in the format specified.
@anmurali, @neil-marcellini, @eh2077 Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!
I have solved the issue and it is now ready for submition
@goldenbear101 Can you post a proposal for this issue? You can refer our https://github.com/Expensify/App/blob/main/contributingGuides/CONTRIBUTING.md
π£ It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? πΈ
Waiting on proposals
Sorry to say but, I do not have the means (connects) to write a proposal on upwork. I request you allow me to operate through Telegram, you would be able to access the work, and only pay after confirmation.
@goldenbear101 You can just post proposals here and we'll review it, see propose-a-solution-for-the-job
The app takes over 30 seconds to open, then a bunch of time to load a chat. Let's focus on the slow opening part specifically, since that's unique to the desktop app.
In https://github.com/Expensify/App/blob/e6c89d9d06f77eca57faa8ef20b236bbfdbc1153/config/electronBuilder.config.js#L38, we don't specify the arch of the desktop build, so electron builder will select based on the machine arch (x64 or arm64), so if I tried to build locally, it will produce an arm64
binaries as I'm using M1 machine, but we are using macos-13 (Intel-based) in the CI, thus using the app built by the CI will be x64
arch.
For x64
app, M1 machine will need to run the app using Rosetta 2 virtualization => slow startup time is expected.
I recommend we build universal
target by supplying in this https://github.com/Expensify/App/blob/e6c89d9d06f77eca57faa8ef20b236bbfdbc1153/config/electronBuilder.config.js#L47
mac: {
....,
target: [
{
target: "dmg",
arch: [
"universal"
]
}
]
}
This will double the desktop app size as it contains both x64
and arm64
binaries.
Another option is to release separate binaries for different archs, this can be done by specifying the x64
, arm64
in the arch
array above.
Obviously, to build the arm64
/universal
arch on CI, we need to update this https://github.com/Expensify/App/blob/e6c89d9d06f77eca57faa8ef20b236bbfdbc1153/.github/workflows/platformDeploy.yml#L137
to macos-14
(macos-14-large
).
NA
Proposal
The desktop app for Mac takes over 30 seconds to open, significantly longer than expected. This issue is unique to the desktop app and affects user experience.
Root Cause The slow startup likely results from:
Slow initialization of application components Inefficient resource loading Network requests made during startup Proposed Changes To solve the problem, the following changes are recommended:
async function initializeApp() {
await loadEssentialComponents();
// Load non-essential components after startup
setTimeout(loadNonEssentialComponents, 0);
}
async function loadResources() {
const [image, data] = await Promise.all([
loadImageAsync('path/to/image.png'),
fetchDataAsync('path/to/data.json'),
]);
}
async function initializeApp() {
await loadEssentialComponents();
setTimeout(() => {
fetchNonCriticalData();
}, 0);
}
Expected Result The app should open quickly, within a few seconds.
By implementing these changes, the startup time of the desktop app should be significantly reduced.
@dominictb your proposal sounds pretty promising. Would you please do some benchmarking / testing for us to gather evidence about how much faster it starts up when built for arm? If you don't have an arm mac, please provide steps for me to test.
@neil-marcellini I'm not sure about benchmarking, will need to think about this. However, you can test this locally since the difference is so evident.
You can try to build the app in both x64
arch and arm64
arch by filling in the electronBuilder.config.js
file
mac: {
....,
target: [
{
target: "dmg",
arch: [
"x64",
"arm64"
]
}
]
}
Then npm run desktop-build
. After that, just check in the desktop-build
folder and compare the startup time of the mac
and mac-arm64
app
I'm testing @dominictb 's proposal
Issue not reproducible during KI retests. (First week)
π£ It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? πΈ
I'll update testing results tomorrow
@anmurali @neil-marcellini @eh2077 this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!
@dominictb this sounds related with https://github.com/Expensify/App/issues/39631#issuecomment-2148278445, right?
@flodnv yup, as explained in https://github.com/Expensify/App/issues/39631#issuecomment-2148278445, these 2 issues are tightly coupled.
I can see significant difference of starting time between universal
and x64
app running on M1 MacBook. I think it's common to create distributables for different hardwares, eg x64
, arm64
and universal
type bundles for macOS. So, @dominictb 's proposal looks good to me.
The other issue seems share some root cause with this issue. #39631 was created earlier though this issue seems has clearer scope. I'm also fine if we decide to put this issue on hold for the older one. Let's defer it to internal engineering team.
πππ C+ reviewed
Triggered auto assignment to @yuwenmemon, see https://stackoverflow.com/c/expensify/questions/7972 for more details.
Unassigning myself as @neil-marcellini is the true Engineer on this issue.
@anmurali, @neil-marcellini, @eh2077 Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!
Not overdue, waiting for @neil-marcellini 's review on https://github.com/Expensify/App/issues/42558#issuecomment-2155182911
I can see significant difference of starting time between
universal
andx64
app running on M1 MacBook. I think it's common to create distributables for different hardwares, egx64
,arm64
anduniversal
type bundles for macOS. So, @dominictb 's proposal looks good to me.
Ok great, I agree! Let's build the desktop app as universal
.
π£ @eh2077 π An offer has been automatically sent to your Upwork account for the Reviewer role π Thanks for contributing to the Expensify app!
π£ @dominictb π An offer has been automatically sent to your Upwork account for the Contributor role π Thanks for contributing to the Expensify app!
Offer link Upwork job Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review π§βπ» Keep in mind: Code of Conduct | Contributing π
I merged that PR, but I want to ask @dominictb @eh2077 how does this work for updating the app? If I click the update menu item in app will it change to being a universal app? If not, how can we make it do that?
@neil-marcellini I haven't check that, will post my findings here soon.
@neil-marcellini according to the documentation, it should download the new binaries and run properly. We could create a test-build branch to test that if you want.
Reviewing
label has been removed, please complete the "BugZero Checklist".
The solution for this issue has been :rocket: deployed to production :rocket: in version 1.4.84-3 and is now subject to a 7-day regression period :calendar:. Here is the list of pull requests that resolve this issue:
If no regressions arise, payment will be issued on 2024-06-24. :confetti_ball:
For reference, here are some details about the assignees on this issue:
BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:
The solution for this issue has been :rocket: deployed to production :rocket: in version 1.4.85-7 and is now subject to a 7-day regression period :calendar:. Here is the list of pull requests that resolve this issue:
If no regressions arise, payment will be issued on 2024-06-28. :confetti_ball:
For reference, here are some details about the assignees on this issue:
BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:
We fixed two issues together here
@mallenexpensify I saw you have handled the payment for the other issue. Can you also take care of this one please? As for the payment arrangement, whatever you all think is best works for me!
@anmurali, @neil-marcellini, @eh2077, @dominictb Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!
Contributor: @dominictb paid $250 via Upwork Contributor+: @eh2077 paid $250 via Upwork
@eh2077 , the PR to fix this that you reviewed also fixed another bug. If you invested additional time on the review, because their was an increase of scope, you might be due additional compensation. Comment if so.
If you havenβt already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!
Version Number: 1.4.75-0 Reproducible in staging?: n Reproducible in production?: n If this was caught during regression testing, add the test name, ID and link from TestRail: Email or phone of affected tester (no customers): Logs: https://stackoverflow.com/c/expensify/questions/4856 Expensify/Expensify Issue URL: Issue reported by: @neil-marcellini Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1716480870229429
Action Performed:
Expected Result:
The app opens quickly, within a few seconds
Actual Result:
The app takes over 30 seconds to open, then a bunch of time to load a chat. Let's focus on the slow opening part specifically, since that's unique to the desktop app.
Workaround:
Unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
Screenshots/Videos
Add any screenshot/video evidence
https://github.com/Expensify/App/assets/38435837/7347b5a4-0e8d-480f-acf5-cfc14a0dead7
View all open jobs on GitHub
Upwork Automation - Do Not Edit
Issue Owner
Current Issue Owner: @anmurali