This question already has answers here:
are extensions bad for performance in swift?
(2 answers)
Closed 3 years ago.
So i have been somewhat thwarted from using extension in my new work place and the reason is that it slows the app down?
Is it true? I cant seem to find any article that verifies this
Cuz i am so used to using extensions to wrap things of similar functionalities, same protocol together.
Extensions do not affect application performance, because in general it's gets compiled into the same machine code, especially when using Whole-Module-Optimization.
However huge number of extensions might affect your app's compile times. Take a look at this benchmark.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I am doing some research on Swift and its differences with Objective-C. From what I could gather, the current version of Swift is quite fast, faster even than Objective-C: see here.
However, since most of these tests are done with sorting algorithms and such, I am wondering if Swift will actually be faster than Objective-C when it is used for development of iOS apps. Can anyone enlighten me on this, preferably from their own experience.
Swift is claimed by Apple to be faster than Objective-C, and as you said it is faster in those sorting algorithms, but for the usage of iOS development, a simple user would not recognize the difference between an app developed in Swift or Objective-C. I developed a lot of apps in Objective-C that are in apple store, and now several in Swift and so far users can not tell the difference if one is much faster than the other.
Swift is unlikely to result in applications that run much faster than applications developed in Objective-C. Even though the two languages are quit different, both target the same Cocoa and Cocoa Touch APIs, iOS and OS X a, both are statically typed languages and both use the same LLVM compiler, so they are not that different after all. There will be performance differences, as the two languages aren't identical after all, but don't expect significant differences.
Swift is also developed from Apple to appeal to new programmers because it is similar to languages such as Ruby and Python than it is Objective-C.
There is a great blog-post about the improvement of Swift performance especially after the Swift 1.2 release.
The author ran several tests with different kind of code like Objc-like Swift code, Swift only and Objective-c only code. And the result was, that Swift 1.2 is much faster than before. He ran tests with JSON so it's a bit more practical than just algorithms.
Beside the 'real' performance, my personal experience about that is, that I'm developing much easier in Swift. I never liked the .h and .m files from Objective-C because it stopped the 'flow of programming'. Also I think the Syntax itself is much easier than in objective-c [with these brackets].
So I think, if you write a new Project from Scratch, Swift is much easier, faster and more elegant. (My opinion)
You can write slow code in any language and Swift is no exception. I haven't had time to fully evaluate the Swift 1.2 Beta but even before most code could be made reasonably fast but it was also very easy to make it very slow. Accessing non-final instance methods especially was very slow and Debug builds were horrifically slow (I have several cases of 100x slower than release builds). A little work to optimise the most deeply nested loops was usually enough to quickly get it somewhere close to C performance.
Most of the code you write is not that performance critical provided you can move slow operations off the main UI queue. More time will be spent in API calls and those will not be affected by the language used to call them. Even where performance is critical the amount of code that needs to be heavily optimised will tend to be small and you could switch to a faster language (e.g. C) for just those parts.
When comparing the Objective-C it is also worth considering what we mean by Objective-C. You can write C functions in Objective-C code and they will result in code as fast as C. I would say that they were C and that to meaningfully talk about Objective-C performance it should be code based on Objective-C message sending and probably NSArrays rather than raw C arrays. If that is the basis Swift (when optimised and using structs and final classes) will come out quite well. However if you are comparing with C code it will usually be the case that Swift will be slower at the moment.
I have a few blog posts about optimising Swift on my blog and I gave a short talk back in October.
Swift comparing to Objective-C has its own benefits like: Swift handles strings more easily, swift tuples offer compound variables, and furthermore, coders don't need to spend time annotating variables with type information and risk making mistakes; in most cases, the compiler can infer the type from the value that a variable is being set with.
Swift is faster compare to Objective-C; that's what Apple's Swift team claims, and it is certainly true. However, the fact is that you have to plan many things in order to write the responsive apps. Here are a few pointers:
Remove unused resources
Optimize resources for ex images
Caching
Compression
Reusable code
Object life management
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I was always frightened by Objective C syntax with all its *, -(), [[]] and so on. Now I am looking at Swift and from my JavaScript background as a frontend developer, I really like its elegance and clear-looking constructions. So, I wonder, do I really need to learn both Objective C (at least basics) and Swift to build apps for new iOS/OSX versions that are coming this fall?
Is there anything I won't be able to do with only Swift? Does Swift have as much access to the API and OS functionality as Objective C does? So, if I don't need to support current Objective C codebase, do I still need it in a real work or can I do all the same things with Swift?
Learning either ObjC or Swift is not the hard part. Work through your fear: it only indicates new things to learn!
Swift is also very much not like Javascript. Don't be fooled by its surface appearance (in fact, avoiding focusing on surface appearance in general is a pretty good plan).
To answer the question though: I would expect it to be a few more years before you won't get a significant benefit from knowing ObjC; there's a LOT of existing code, examples, docs, etc... all in ObjC. But there's little to nothing in the system APIs that will require it once Swift 1.0 is actually out.
Of course, this depends very much on what you are planning to do. But I think there are a some points you should consider:
Performance
According to this SO question the performance is not as good as Apple promised (yet). But if you care about high performance, you should wonder if Objective-C is your way to go.
C++ Code
Very important is the fact, that you cannot use C++ code in your Swift code without having a Objective-C(++) wrapper:
You cannot import C++ code directly into Swift. Instead, create an
Objective-C or C wrapper for C++ code.
from the Apple Swift Documentation.
Platform
Swift uses the same runtime as the existing Objective-C system and the idea of Automatic Reference Counting. So in my humble opinion a basic knowledge of Objective-C and the ideas behind helps to write better and more performant Swift code.
Existing Work
It will take some time that all frameworks, methods, classes, etc. have a pure Swift interface. Almost every demo project from Apple is written in Objective-C, too.
Conclusion
So I think, you will need some basic Objective-C knowledge in the future - maybe this changes over time. But it depends very much on what you are planing to do.
Is there anything I won't be able to do with only Swift?
Yep - if you need to support cross-platform or legacy code bases with C or C++ code there's no way yet (an not in the foreseeable future) this could be done with Swift.
I think, it's better to read about Objective-C, at least basic things in order to be able to read it, because if you are going to be an iOS/Mac developer, the chances are high that at some point you'll have to interact with Objective-C code somehow (for instance, you might need to take a look at some third party library code). Learning the basics doesn't take much time, Objective-C is actually a rather simple language. It's just not very pretty :)
The other possible necessity for Objective-C is a code optimization. High performance parts of code are often written in pure C/C++. You can't mix C/C++ code with Swift. The only way you can do it is by using an Objective-C/Objective-C++ wrapper for your C/C++ code. And that's when you're going to need Objective-C knowledge.
But actually it's possible, if I'm not mistaken, to use just Swift for development. So, my advice is the following: if you really hate Objective-C, use Swift as the main development language, but learn Objective-C basics in order to be able to read it (at least). Just in case.
This question already has answers here:
Why should I not wrap every block in "try"-"catch"?
(16 answers)
What are the best practices for exceptions/returning NO/nil in Objective-C?
(4 answers)
Closed 9 years ago.
I used to work in .NET c# and recently I started learning objective-c and iOS programming. Several times I've read that objective-c is exception unfriendly and I shouldn't handle them. I know it's better to don't cause any exception, but aren't they created for securing our code? Exception handling is very common in .NET and I can't understand why I shouldn't do this in objective-c.
Even in .NET, exceptions are not meant for program flow. The fact that some programmers use them as such is just bad programming. The performance is terrible. Often you will see programs that display error messages from exception handling that make no sense to the end user. This kind of design makes an application not crash, but does not offer an end user much information.
You can use exceptions as program flow just like you do in .NET. There is nothing stopping you. The performance hit is probably actually less than in .NET.
The reason you shouldn't is because those exceptions happen for a reason. You aren't using the frameworks appropriately. You haven't implemented something fully. Etc.
This question already has answers here:
To ARC or not to ARC? What are the pros and cons? [closed]
(6 answers)
Closed 9 years ago.
I am taking a class (computer based training on Lynda.com) and the instructor goes on and on about using "release" for your objects. This course was created in 2011 and clearly Apple has updated their product to do the release for you automatically. While I know I can go back to a manual mode and release items myself (eg turn off ARC), my question is this: what is the best practice? Should I leave ARC on or turn it off? Perhaps you have a good example as to when I should make this choice?
Also, if I am totally off base on this, your help is appreciated as well :-)
Thanks.
There is no reason to start a new project today that does not use ARC.
However, learning how to do memory management through retain/release may be useful if you are hoping to work as an iOS developer on existing projects, since in many older codebases memory management is still done manually.
What is the best practice? Should I leave ARC on or turn it off?
Best practice is using ARC for all new development, and selectively turning ARC off only for legacy libraries.
Perhaps you have a good example as to when I should make this choice?
The choice is very simple: if you are maintaining a large body of code with manual memory management, turn ARC off; otherwise, keep ARC on.
It is still very beneficial to get a working knowledge on how retain/release work: it would let you understand ARC at a deeper level.
As a side note, consider switching the course to something that has been updated in the last two years: ARC is easily the most important change in the language that has been introduced in the last few years; you definitely do not want to miss out on it.
This question already has answers here:
Generating GUIDs in Ruby
(11 answers)
Closed 10 years ago.
I am looking for a list of UUID gems for Ruby on Rails, could someone please recommend a couple to me, preferably ones that are not so complicated that I wouldn't be able to understand them easily.
The Ruby Toolbox is a nice place to start your search.
I would strongly recommend you to use UUID Tools
A brief of what they offer:
UUIDTools was designed to be a simple library for generating any of
the various types of UUIDs. It conforms to RFC 4122 whenever possible.
I have been using it for different projects and I haven't had any problems. Also, the documentation is pretty good. Check this out for more reference UUID Tools Reference