What is the string you are using for the identifier? All the code I have seen from India that I have seen (from maybe 5 different developers) using a cell identifier - for SOME REASON - makes the identifier for each cell a different value.
Are you using one value for the identifier or is it a random value each time you create the cell? > On Jan 10, 2018, at 11:56 AM, David Duncan <david.dun...@apple.com> wrote: > > >> On Jan 10, 2018, at 3:48 AM, Devarshi Kulshreshtha >> <devarshi.bluec...@gmail.com> wrote: >> >> I had a discussion with my colleagues regarding use >> of dequeueReusableCellWithIdentifier, few of them are under assumption that >> if there are less number of cells it is better to directly alloc init a >> UITableViewCell in place of using dequeueReusableCellWithIdentifier. They >> are saying that since at a time almost all the cells will be displayed >> there is no need to use dequeueReusableCellWithIdentifier because it >> degrades performance in comparison to alloc init, in such scenarios. My >> understanding is that there is no any performance cost as such and behind >> the scenes dequeueReusableCellWithIdentifier is doing the same thing >> (allocating and initializing) if a cell cannot be reused. >> >> Is there any way I can compare the performance of using >> dequeueReusableCellWithIdentifier versus using directly alloc init and >> share with them to come to a conclusion? Please suggest. > > The overhead of calling dequeueReusableCellWithIdentifier: should be > extremely minimal. The static/short table case is actually more likely to be > a case where breaking the standard pattern is only going to lead to future > maintenance headaches vs achieving any significant performance improvements. > > If you want to measure the difference, you would probably just call > alloc/init vs dequeue in a tight loop and measure the total time taken. If > you find a case that seems problematic, it would be worth a bug report. > >> >> -- >> Thanks, >> >> Devarshi >> _______________________________________________ >> >> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >> >> Please do not post admin requests or moderator comments to the list. >> Contact the moderators at cocoa-dev-admins(at)lists.apple.com >> >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/cocoa-dev/david.duncan%40apple.com >> >> This email sent to david.dun...@apple.com > > -- > David Duncan > > _______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com > > This email sent to z...@mac.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
