Thanks Karl for the feedback, my memory is on the low side and maybe causing some of the issues, the hdd is a bit clunky too, I certainly notice a slow down when disk writes/reads are happening, so the ssd should make a difference in that area, it is funny how apple and windows are very closely aligned I would say that 4gb is the bare minimum on windows and that looks the same on apple. I might throw some more ram in my current mac book, I will see if I can borrow some from a friend, my macbook maybe too old.
But I think in the long run, with memory requirements increasing at the pace they have for over 20 years, I would be better off getting a macbook that supports 16gb that will future proof it for a while. thanks again. ATB Alex On 28 Sep 2012, at 16:52, Karl Heinz Brehme Arredondo <[email protected]> wrote: > Hi Alex, maybe useless but that's my spec and I have no issues (I'm not yet > with MonoTouch 6) and all is done with IB, with more than 30 xibs/forms cross > platform with Windows Mobile: > > Nome do Modelo: MacBook Pro > Identificador do Modelo: MacBookPro7,1 > Nome do Processador: Intel Core 2 Duo > Velocidade do Processador: 2,4 GHz > Número de Processadores: 1 > Número Total de Núcleos: 2 > Cache de L2: 3 MB > Memória: 8 GB > Velocidade do Bus: 1,07 GHz > > It's something better than what you use but not so better, and the project is > small... Memory is "high" just because I use Fusion with Windows VM and in 1 > week it go to almost 0 MB free + Office 2011... > > My only desired change is to change to a SSD disk (and for the VM, a > quadcore... but) > > Karl > > Em 28/09/2012, às 11:44, Alex White escreveu: > >> Hi Jeff, >> >> Thanks for looking at the logs you have found what I thought you would, race >> conditions, of course in the perfect world we would have perfect performance >> so that some of these did not occur, but as with all things programming, if >> it can go wrong it is only a matter of time before it does. >> >> Get me a link to the build and I will have a good go with it, I will still >> consider the move up to better hardware but in the short term that is not >> going to happen and it gives us an opportunity to resolve some of these >> types of issues, what I will do is clear down my Xcode logs once installed >> then give it a hammering over the next couple of days. >> >> Whilst this has been frustrating to say the least, I am really happy with >> the support I am getting and I am sure we will get to the bottom of things. >> >> ATB >> >> Alex >> >> >> On 28 Sep 2012, at 15:20, Jeff Stedfast <[email protected]> wrote: >> >>> Hi Alex, >>> >>> It's worth investigating. I can make no guarantees that your current >>> hardware is the cause of the xcode syncing problem, of course, but it's >>> possible. Upgrading your hardware certainly wouldn't hurt. A year ago when >>> I was doing a lot of work on the Xcode syncing stuff, I was finding that >>> 4GB of RAM for running 2 copies of MonoDevelop (debugging MonoDevelop >>> inside MonoDevelop) and Xcode side-by-side was a bit on the slow side and >>> once I upgraded my RAM, things ran a lot faster. 8GB of RAM and an SSD >>> should improve things a lot for you. >>> >>> That said, I did find one error in the log files you sent me yesterday >>> indicating a race condition that caused an NRE during one of the last syncs >>> in your most recent MonoDevelop session. I'm not 100% sure that it is the >>> cause of the failure to sync, but it might be. The problem is that I'm not >>> sure how the race was happening (the only way I can see how it could have >>> happened is if our AppleSdkSettings object emitted a Changed event >>> mid-sync, but I'm not sure how that could happen). That was the only >>> code-path that didn't do the proper locking before modifying some internal >>> state variables used by the syncing process. I've added the proper locking >>> for an upcoming MonoDevelop 3.0.4.8 release (I can provide a pre-release >>> download for you as soon as I get to the office). Maybe you can test it out >>> for a few days and see if it seems to solve the issue for you. >>> >>> Hope that helps, >>> >>> Jeff >>> >>> On Fri, Sep 28, 2012 at 3:54 AM, Alex White <[email protected]> wrote: >>> Hi Jeff, >>> >>> My issues could come down to the performance of my MacBook it is pretty old >>> a dual core, 4gb of ram, how much better does monodevelop run on a quad >>> core, I see my CPU max'ed out for many minutes at a time when compiling is >>> happening, memory seems to be ok so I am guessing there is not excessive >>> paging of memory, so it comes down to CPU and a bit of hdd. >>> >>> my current MacBook is:- >>> >>> Model Name: MacBook Pro >>> Model Identifier: MacBookPro3,1 >>> Processor Name: Intel Core 2 Duo >>> Processor Speed: 2.2 GHz >>> Number of Processors: 1 >>> Total Number of Cores: 2 >>> L2 Cache: 4 MB >>> Memory: 4 GB >>> Bus Speed: 800 MHz >>> >>> I am contemplating a quad core 15" with a solid state hdd with 8gb of ram, >>> I need to reduce the compile round trip times significantly if I can, is it >>> worth investigating this route? >>> >>> >>> ATB >>> >>> Alex >>> >>> >>> On 27 Sep 2012, at 17:05, Jeff Stedfast <[email protected]> wrote: >>> >>>> Hi Alex, >>>> >>>> On Thu, Sep 27, 2012 at 7:24 AM, Alex White <[email protected]> wrote: >>>> Hi Jeff, >>>> >>>> thanks for the reply, >>>> >>>> This problems has been occurring on and off for months, but in the last >>>> week 100% of the Xcode updates are no making their way into MonoDevelop it >>>> has forced me to recode my project to be xib free, it does not help that >>>> this happened right in the middle of a load of work with beta testers, but >>>> an xib free app should be better in the long run. I have had so many >>>> crashes that always report, some in MonoDevelop and some in Xcode, I have >>>> also noted that there are times where the sync'ing back to MonoDevelop has >>>> crashed both MonoDevelop and XCode at the same time, both needing to be >>>> forced to quit which does not make sense to me as the sync'ing from what I >>>> can see is not done via processes but file watching if you see my logic. >>>> >>>> There's some IPC (via AppleScripting) between MonoDevelop and Xcode as >>>> well, during the syncing process, so this might explain that. >>>> >>>> >>>> I will in future use Xcode to only prototype screen layouts then creating >>>> the views programatically. >>>> >>>> Not only do I have to create them from scratch but I cannot use the >>>> original names as this throws up so many errors that I cannot fix, I have >>>> so many views now with 2's or 3's on the end of them. Also a side issue is >>>> renaming of objects in Xcode I have never got this to work properly and be >>>> reflected back in MonoDevelop but that is another issue, but having many >>>> objects that have the wrong name is not good. >>>> >>>> Where are the timeouts?, I will have a play with them if they are >>>> available to me. >>>> >>>> Unfortunately, they are not available for users to tweak (they are >>>> currently hard-coded in MonoDevelop). MonoDevelop's XcodeSync log file >>>> would help me figure out if it is related to the timeouts at all, or if it >>>> is something else. >>>> >>>> >>>> I will do some further testing before I go down the route of logging a bug. >>>> >>>> If you can get your hands on the appropriate XcodeSync log file in the >>>> MonoDevelop log directory, that might be enough. I added some fairly >>>> verbose debugging WriteLines in MonoDevelop's syncing logic in order to >>>> make it easier for me to debug these kinds of issues. >>>> >>>> You should be able to find them in >>>> /Users/<name>/Library/Logs/MonoDevelop-3.0/Xcode*.log >>>> >>>> Hope that helps, >>>> >>>> Jeff >>> >>> >> >> _______________________________________________ >> MonoTouch mailing list >> [email protected] >> http://lists.ximian.com/mailman/listinfo/monotouch >
_______________________________________________ MonoTouch mailing list [email protected] http://lists.ximian.com/mailman/listinfo/monotouch
