Jump to content

Community input on possible size increase (and related benefits)


Firon

Recommended Posts

We would like to switch to MSVC2005 to avoid various compiler bugs in MSVC6 (our current compiler). These bugs cause crash issues and other strange problems that require a significant amount of development time to work around, time which could be spent fixing other problems and implementing various improvements.

However, if we do this, µTorrent's filesize would increase 40-50k (packed). I'm making this post to hear your input on whether you guys would mind the size increase. The memory footprint and CPU usage would not change by any noticeable amount (either increase or decrease).

We are also considering switching to an SSL library instead of using the built-in Windows functions. This would allow more parallel connections to a single server (wininet limits you to 2 at once to a particular server), avoid the annoying SSL certificate errors you sometimes get, and also allow the WebUI and embedded tracker to work over SSL without needing stunnel. This would also increase filesize anywhere from 30 to 50k. The memory footprint and CPU usage should also not be noticeably different.

We will of course still strive to keep it as small as possible, as well as keep memory and CPU usage low.

Link to comment
Share on other sites

100k is an almost negligible amount of data, but when five or six orders of magnitude are involved, it becomes a server issue. E.g., if 100,000 people downloaded 100kb, that'd be 9.5gb.

...if uTorrent is becoming truly insanely popular (I have no idea how many thousands of each release are downloaded), you may wish to implement an Azureus-style torrent updating scheme so the distributed user-base can carry the load rather than your own bandwidth.

Link to comment
Share on other sites

µTorrent has been kept ridiculously small for some time.

...There is no reason to keep doing so if it gets in the way of bug fixing and adding of very useful features.

Even if µTorrent "bloats" to 1 MegaBYTE in size, it still would be the smallest feature-packed BitTorrent client. (There are smaller, but they lack features.)

Link to comment
Share on other sites

Hopefully this doesn't convince people otherwise, as we are very focused on keeping it small - a lot of work has been done on 1.8 to remove some of the code bloat from 1.7, so despite having a lot of huge new features (some unannounced) it should be very similar in size; at least for now the goal is still to keep it as small as possible.

Link to comment
Share on other sites

Although the very small packed download size is a fun extra (that speaks directly to the less computer savvy amongst us) it has always really been about the memory footprint and the resource consumption that gave µtorrent its sleek reputation. I think keeping the packed size small should be a consideration, yes. But it should be secondary to most other aspects of the program (which includes stability).

So a different packer wouldn't really matter in that aspect. Besides a 300kb download is still relatively small compared to the size of the torrents that will be downloaded using µtorrent.

What is the impact of the SLL library on the memory footprint. And will it make running µTorrent (all things considered) on slow machines and old windows versions more problematic or is the effect negligible?

I myself don't mind much because I run µtorrent on the background of a powerful machine and it has virtually no inpact on any of the main applications. Even if you doubled the CPU usage I don't think I'd notice. But I think the above questions are the most relevant to the people who really value the sleekness of µtorrent above all else.

Link to comment
Share on other sites

I think keeping the packed size small should be a consideration, yes. But it should be secondary to most other aspects of the program (which includes stability).

That's pretty much my sentiment too. In the end, we're still talking about a full-featured client, compatible over multiple generations of Windows (and some other OSes, with help), in less than 512kiB... :).

The ~45k for the sake of stability/reliability/maintainability is a no brainer. Balancing size/features could be a little trickier, but considering past evolution of µTorrent, I'm confident it'll be allright. You can always cut µTris out again if need be ;p.

Link to comment
Share on other sites

Because we still wanna keep support for it.

Estimates are that it's <1% of the userbase, but.. still, why not? :P

By compiling the latest build of µTorrent with MSVC2005, the filesize increase after packing was 37kB. It's being tested now to ensure it works properly on 9x/ME/NT.

Link to comment
Share on other sites

Personally I don't like the code produced by MSVC2005/MSVC2008 (prefer MSVC2003 one). But of cource it will be way better than MSVC6 with its bugs.

If you'd use only simple standard library functions like strcpy, strcmp and instead of complex functions like stricmp, fopen use WinAPI equivalents - it's possible to strip CRT startup, so your compiled size will not increase significantly and exe will not depend on any additional dll. (Easy to do on MSVC2003, a little tricky on MSVC2005/MSVC2008.)

If you'd link with MSVC2005 CRT in dll like you do it now... well, it'll be not good at all since, unlike msvcrt.dll, msvcr80.dll is not installed with windows and users will have to find it themselves.

If you'll decide to go with MSVC2005 and not MSVC2003/MSVC2008 - disable there code optimization for Pentium4 (default behaviour), since it's not optimal for both older and newer processors.

At last, a little request - please, publish uncompressed version as well as upx'ed. (Uncompressed version is more memory-efficient at runtime.) It's not hard to unpack it, but this way you lose digital signature.

Link to comment
Share on other sites

1. For me the "smallness" of uT was never about the filesize, but the cpu/memory footprint.

2. Wu use uT to move around TBs of data, bitching about 100k would be idiotic...

Still, keeping the program relatively small is a good idea for portability, but the current filesize is so small that I don't see how you can break that unless you start putting porn pics in the exe :P

Link to comment
Share on other sites

  • 3 weeks later...

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...