MemeCode - Blog

Page: 0 ... 5 ... 10 ... 15 20 21 22 23 24 25 26 27 28 ... 30 ... 35 ... 40 ... 45 ... 50 ... 55 ... 60 ... 65 ... 70 ... 75 ... 80 ... 85

Registering Visual C++ 2008
Date: 16/3/2009	So you need to register Visual C++ 2008? sigh Well, you can sign up for a MS Live ID and go through the loopholes. One thing to note is that you can use any bogas email address you like, they DON'T ACTUALLY CHECK IT! Which is nice I guess. Or alternatively, just use this key: PG1G5VXHH5NTG1
(0) Comments \| Add Comment

Google Adwords
Date: 11/3/2009	I've gone and removed all the Google ads off this site. It was fun for a while, but now I don't get paid for it anymore so they're gone. The return on Adwords has gone from very decent to non existent, with zero changes on my part. Maybe I could frig with it for bit to improve it somewhat, but no I have better things to do with my time.
(0) Comments \| Add Comment

Minidumps
Date: 4/3/2009	I've moved all new Win32 Lgi application builds to output minidumps when they crash (if Dbghelp.dll is present) instead of trying to create there own stack trace. I just found that it's too unreliable. Recent Visual C++ builds do a fair job of loading the minidumps and telling you about the conditions of the crash, and I have the free version of 2008 installed on my machine. Surprisingly it even works with apps built with Visual C++ 6, which is still my primary compiler on windows (Speed baby... all speed!). I will experiment with optionally reporting the crash dumps back to myself when the application re-starts. Hopefully this will reduce the amount of time it takes to get crashes fixed.
(0) Comments \| Add Comment

I Need A New Phone...
Date: 25/2/2009	I'll be working on this sheet over the next week or so... and you can see how things progress. Spreedsheet... Columns: 3G: Must have 2100 3g capabilities (I'm currently with Three) USB Mass Storage: Must be able to act as a USB mass storage device when connected to a computer. Charge over USB: Must be able to charge the battery over USB. Via an adapter if necessary (although I'd rather avoid adapters if I can). Nokia generally suck in this area. 3.5mm audio jack: Should have a 3.5mm jack for headphones. Not a show stopper but I'd like the convenience. MP3/AAC: I have a bunch of MP3/AAC's and I'd like to be able to use my phone as a media player. Decent media functions is a must. H264: Must be able to playback iPod style video, aka 300-450kbit H264+AAC @ 320x240px video. Must handle videos over 1hr in length. I occasionally get stuck somewhere killing time and having a couple of movies on the phone is the best. Camera: Must have an average 2MP camera. A bad camera will rule the phone out, must not suck completely. If it takes reasonable video as well, bonus! (Current phone's video recording is a joke of a slideshow) Fast Menus: Showing/navigating menus must be near instantaneous, no excuses. PC Sync: Should be able to replicate contacts and calendar events to an open format or API on a computer without using the bundled tools (which invariably suck). Call Quality: Must have clear call quality with decent reception. No lemons please. Battery life: Must have a standby of 4 days min (no music or serious usage). Call time not an issue. Web Browser: Reasonable web browser, not WAP. Not a deal breaker but I'd like to be able to look some things up on the go. Price: Looking at getting something used below $250. Unless it's an iPhone, which is probably worth whatever you pay for it. Killer combo on almost all fronts, still I'm hoping I can line up something I can live with for a lot less. (Items that have been striked out are no longer being considered) Update: I've won a k800i on the 'bay ($96aud+s/h) and I'll see how that goes for a month or 2. If it doesn't annoy the snot out of me that'll be it for a year or 2 otherwise I'll chuck it back on the 'bay and try something else. The 6600 slide is a bit steep at the moment though. One of my friends has a k800i so I checked that it plays mpeg4 properly. And while it doesn't have the grunt for higher bitrates I found a reasonable compromise with mp4 (mpeg4 @ 430kbps, 320x240 + aac @ 64kbps). If the video bitrate is too high it skips, like up around 500kbps. I couldn't test seeking and longer movies because they didn't have a memory card. But I'm reasonably sure it'll be ok. If not there is always ebay. Update: The one from ebay wasn't good, all sorts of problems. Wouldn't stay on, screen would go all white and become unresponsive and sometimes wouldn't turn on. Fun fun fun! Fortunately the seller is prepared to accept returns, so I'm back looking for another one as I've already bought a 4gb M2 card.
(3) Comments \| Add Comment

Memory
Date: 10/2/2009	Today I did some work on the memory foot print of Scribe v2.x at startup with a large folder file and the results are in. This morning I started with a virtual memory foot print of: 82,596 kb Which includes all data and a lot of overhead in the memory tracking lib. The absolute figure is not really important. So I analyzed the blocks and found a huge pile of them in the Xml parser. It's blocks are primarily from loading the lr8 file and keep the Xml DOM around in memory to build dialogs, strings and menus from. So I changed that over to a ref counted string pool, that cut down a huge number of tiny allocs to a few big ones. Saves on overhead... also I free'd some of the tags I didn't need anymore. Now the footprint stands at: 72,288 kb A good start, but what else can be done? So I did a live memory dump of Scribe running at idle after startup. And after fixing some issues with the dumping and reporting I had the results, the largest allocator in the code was creating 24.3MB in 52,924 allocations from Store3Mail2.cpp:119. So I looked at that line: return new MailData(this); So I looked at the size of that object, and it's over 400 bytes. Owwww, that doesn't sound right. So I dug through the members and isolated the object blowing the size out. There was no easy way to remove the bulk of that object as it inherits from UI objects, however there is no real need to use that exact object, so I reimplemented a smaller implementation of the required interfaces and got the size of the MailData object down to 280 bytes. That brings the total memory footprint down to: 41,736 kb Even nicer... Thats not bad eh! Half the memory usage. Update: So today I did some more snooping around the memory footprint and found that all the mail2 folders are loading their entire contents into memory as objects. Normally I delay loading of items till they are needed, or at least thats the way it worked in v1.x, so I changed the Store3/Mail2 backend to work the same way as v1 and delay loading objects... 20,700 kb Damn straight.
(1) Comment \| Add Comment

Memory

Date: 10/2/2009

Today I did some work on the memory foot print of Scribe v2.x at startup with a large folder file and the results are in. This morning I started with a virtual memory foot print of:

82,596 kb

Which includes all data and a lot of overhead in the memory tracking lib. The absolute figure is not really important. So I analyzed the blocks and found a huge pile of them in the Xml parser. It's blocks are primarily from loading the lr8 file and keep the Xml DOM around in memory to build dialogs, strings and menus from. So I changed that over to a ref counted string pool, that cut down a huge number of tiny allocs to a few big ones. Saves on overhead... also I free'd some of the tags I didn't need anymore. Now the footprint stands at:

72,288 kb

A good start, but what else can be done? So I did a live memory dump of Scribe running at idle after startup. And after fixing some issues with the dumping and reporting I had the results, the largest allocator in the code was creating 24.3MB in 52,924 allocations from Store3Mail2.cpp:119. So I looked at that line:

return new MailData(this);

So I looked at the size of that object, and it's over 400 bytes. Owwww, that doesn't sound right. So I dug through the members and isolated the object blowing the size out. There was no easy way to remove the bulk of that object as it inherits from UI objects, however there is no real need to use that exact object, so I reimplemented a smaller implementation of the required interfaces and got the size of the MailData object down to 280 bytes. That brings the total memory footprint down to:

41,736 kb

Even nicer... Thats not bad eh! Half the memory usage.

Update: So today I did some more snooping around the memory footprint and found that all the mail2 folders are loading their entire contents into memory as objects. Normally I delay loading of items till they are needed, or at least thats the way it worked in v1.x, so I changed the Store3/Mail2 backend to work the same way as v1 and delay loading objects...

20,700 kb

Damn straight.

(1) Comment | Add Comment

Work Update
Date: 27/1/2009	I've been working away on the Linux XCB port and got to a point where the keyboard and dialogs now work mostly. Which is a decent milestone. There doesn't appear to be any support whatsoever for XCB to use input managers. So this year I hope to investigate that and maybe contribute something to XCB library to fill that functionality. On the Mac front I've been working on getting native controls to play nicely with the custom Lgi controls, specifically the native scrollbars. So far I have that working but it crashes in carbon somewhere after it accesses a HIView that I just detached from the heirarchy and CFRelease'd. And I'm stuck in a hole trying to fix that. Which is very annoying.
(0) Comments \| Add Comment

Sitemap