Just make the changes, we will see what happens.
In the meantime, is the sparse setting on Account with dynamic calc causing any issue on retrieving from Smart View?
Well, sparse dynamic calcs are what gives rise to this problem in the first place - the issue is that in order to answer your query, Essbase has to pull in lots of blocks and then dynamically calculate a result from them.
So if you query a sparse account that is at the top of a dynamic tree that goes down to 100 input accounts, Essbase has to pull all 100 blocks to answer the query.
But dense / sparse settings aren't something you can change without a lot of thought on the possible consequences, especially for calculation.
I kind of suspect that may have something to do with the slow retrieve, what are some of things need to be careful when I change dimension from sparse to dense (I know I want to change from account from sparse to dense)?
It will change the size of the cube on disk, but it also changes default calculation order so you have to do functional testing of dynamic calcs and calc scripts very carefully. It also changes which blocks get created - for example, let's say Period is dense, and someone has written a calc that depends on a value being loaded to "January" to create the block that contains the rest of year; if you make Period sparse, that no longer works.
It can alter the performance of loads and queries.
It changes rules about which dimensions can be tagged as e.g. Accounts, Time, or have Attributes associated.
There are probably several others I'm forgetting - in short, once you change dense/sparse configuration in a cube it will require very extensive re-testing of pretty much everything from dimension builds to data loads to calculations to queries.