- #Netnewswire android serial
- #Netnewswire android full
- #Netnewswire android code
- #Netnewswire android download
The database work, more than anything else, is why NetNewsWire is fast. I could, and probably should, write more articles going into details here.
#Netnewswire android full
To make searching fast, we use SQLite’s Full Text Search extension. (Not sure that matters to performance: we just happen to like structs.) We use structs instead of classes, as much as possible, for model objects.
#Netnewswire android serial
We run the database on a serial queue so we don’t block the main thread. We use various tools - such as EXPLAIN QUERY PLAN - to make sure we’ve made fetching, counting, and updating fast and efficient. (Remember that Core Data manages a graph of objects: it’s not a database.) We can optimize our schema, indexes, and queries in ways that are outside the scope of Core Data. While Core Data is great, we use SQLite more directly, via FMDB, because this gives us the ability to treat our database as a database. Custom Databaseįor an app that is, again, just a fancy database browser, this is where the whole thing can be won or lost. So, instead, we coalesce these - we make it so that recalculating unread counts happens not more often than once every 0.25 seconds (for instance). For instance, during a refresh, the app could recalculate the unread count on every single change - but this could mean a ton of work. We also try to coalesce other kinds of work. This way the database is updated once, the unread counts are updated once, and we push just one action on the undo stack. The same API that marks a single article as read is used to mark 10,000 articles as read. We have specific APIs for actions like this, and those APIs expect a collection of objects. You could call article.read = true for each article - and, for each article, trigger a whole bunch of work. Now say you’re marking all articles in the current timeline as read. Calling article.read = true triggers, via KVO or notifications or something, things like database updates, user interface updates, unread count updating, undo stack maintenance, etc. Say a user is marking an article as read. Here’s an example of a trap that’s easy to fall into. (A simple example of a background thing, besides feed parsing, is creating thumbnails of feed icons.) We Avoid the Single-Change-Plus-Notifications Trap They shouldn’t trigger KVO or other kinds of notifications as they do their work. The key is, of course, making sure your operations are in fact self-contained.
When an operation can be made self-contained - when it can just do a thing and then call back to the main thread, without threading issues - we use a serial queue if there’s any chance it could noticeably block the main thread.
#Netnewswire android code
The parser isn’t the only code we run on a serial queue. If the hash matches the hash from the last time, then we know the content hasn’t been modified, and we skip parsing.
#Netnewswire android download
We also create a hash of the raw feed content whenever we download a feed. We use conditional GET, which gives the server the chance to respond with a 304 Not Modified, and no content, when a feed hasn’t changed since the last time we asked for it. The parsers are fast - but we also do our best to skip parsing entirely when we can. Since parsing is a self-contained operation - we input some data and get back objects - there are no threading issues. That’s fast, but we do another thing as well: run the parser in the background on a serial queue. On my 2012 iMac, parsing a local copy of some past instance of the Daring Fireball Atom feed - relatively large at 112K in size - happens in 0.009 seconds. The most painful way to parse XML is with a SAX parser - but it’s also how you’ll get the best performance and use the least memory. The below items are in no particular order. Because NetNewsWire is - like many apps these days - basically a fancy database browser where data comes from the web, some of these will apply to other apps. Make sure, in other words, that performance isn’t just a topping - it’s the pizza.īelow are some of the specific reasons NetNewsWire is fast. Make sure it‘s part of every decision every day. The best general advice I can give is just this: make sure performance is part of the foundation of your app. If you take a month or two to speed things up, from time to time, your app will always be - at best - just kind of heading toward satisfactory, but never to arrive. I suspect that it’s hard to do this any other way. Being fast is part of the very definition of the app. NetNewsWire is fast because performance is one of our core values.
0 kommentar(er)
