aboutsummaryrefslogtreecommitdiffstats
path: root/Source/SPDataStorage.h
Commit message (Collapse)AuthorAgeFilesLines
* Move some code to a place where it makes more sense to be (part of #2770)Max2017-04-181-0/+7
| | | | (This should not cause any behavioral changes)
* Remove debug code for #2163Max2016-07-101-3/+0
| | | | Issue last seen with NB 4644 on 2016-01-21. Seems to be fixed.
* Additional debug code for #2163Max2015-10-051-0/+3
|
* Update NSPointerArray usage in SPDataStorage for 10.9 SDK, tracking edited ↵rowanbeentje2014-02-041-0/+1
| | | | row count and using for fast bounds checks; this should fix #1884
* Update URL in source file header to point to GitHub.Stuart Connolly2014-01-261-1/+1
|
* Remove SVN property placeholder.Stuart Connolly2014-01-261-2/+0
|
* Rework table content and custom query data loading and storage for speed ↵rowanbeentje2013-08-131-29/+39
| | | | | | | | | increases and lower memory usage: - Add a new SPMySQLStreamingResultStore class to SPMySQL.framework. This class acts as both a result set and a data store for the accompanying data, storing the row information in a custom format in a custom malloc zone. - Amend SPDataStorage to wrap the new class, so original result information is stored in the one location in the custom format. Any edited information is handled by SPDataStorage for clean separation - Rework table content and custom query data data stores to use the new class. This significantly speeds up data loading, resulting in faster data loads if they weren't previously network constrained, or lower CPU usage otherwise. The memory usage is also lowered, with the memory overhead for many small cells being enormously reduced.
* Change Sequel Pro's license from GPL (version 2) to MIT.stuconnolly2012-07-251-20/+23
|
* Tidy up.stuconnolly2010-10-191-4/+8
|
* Add a new SPDataStorage class, and use it in TableContent and CustomQuery:rowanbeentje2010-01-171-0/+101
- SPDataStorage is a class designed for a 2D array of fixed-width data storage, replacing the current method of nested NSMutableArrays. NSFastEnumerator compatible. - Overall memory overhead for table storage in memory reduced by 1.2-1.4x - this almost gains back the large memory jump seen for 64 bit - Some operations (adding data, retrieving a single cell's data) are faster than nested NSMutableArrays; some operations (requesting a row as an NSArray) are slightly slower as the data needs to be converted, but overall result is a slight speed gain. (- Could be used in future to store SQL results in C datatypes, avoiding very high NSObject overhead for numbers and short strings)