Quantcast

Maximum PC

It is currently Wed Oct 01, 2014 9:39 pm

All times are UTC - 8 hours




Post new topic Reply to topic  [ 28 posts ]  Go to page Previous  1, 2

What is your favorite Programming Language?
Poll ended at Fri Dec 31, 2004 1:05 pm
C/C++ 43%  43%  [ 3 ]
C# 0%  0%  [ 0 ]
Java 29%  29%  [ 2 ]
VB 0%  0%  [ 0 ]
PHP 0%  0%  [ 0 ]
LISP 0%  0%  [ 0 ]
LISP 0%  0%  [ 0 ]
Perl 14%  14%  [ 1 ]
Python 14%  14%  [ 1 ]
Total votes : 7
Author Message
 Post subject:
PostPosted: Wed Dec 29, 2004 9:26 pm 
Bitchin' Fast 3D Z8000*
Bitchin' Fast 3D Z8000*
User avatar

Joined: Tue Jun 29, 2004 11:32 pm
Posts: 2555
Location: Somewhere between compilation and linking
Kybo_Ren wrote:
Interesting.

Now there's just one question: Why the f*** is Azureus using so much memory? There's no reason X_X

I haven't profiled Azureus or anything, but it seemed like it had quite a few features, eg, the stats were pretty neat. All that stuff adds up. Also, it uses SWT and not AWT or Swing - maybe there is some additional overhead for some reason.


Top
  Profile  
 
 Post subject:
PostPosted: Thu Dec 30, 2004 1:58 am 
Team Member Top 100
Team Member Top 100

Joined: Fri Sep 17, 2004 5:35 pm
Posts: 1176
But here's the kicker:
If I minimize Azureus and wait for a bit, usage drops down to 10MB.

Does Azureus really need 30MB to draw one page? Sheesh. Must be a lot of stuff then.


Top
  Profile  
 
 Post subject:
PostPosted: Thu Dec 30, 2004 4:29 pm 
iron colbinator
iron colbinator
User avatar

Joined: Tue May 25, 2004 2:25 pm
Posts: 2761
Location: Washington, the state
Kybo_Ren wrote:
But here's the kicker:
If I minimize Azureus and wait for a bit, usage drops down to 10MB.

Does Azureus really need 30MB to draw one page? Sheesh. Must be a lot of stuff then.


You know what, a lot of Java apps do that. I think the GUI programmers just weren't clean about cleaning up their images and whatnot after they were drawn on the screen, OR the JVM isn't clean about it. When you minimize, things that were "drawn" get to be garbage collected, then drawn from scratch again when you bring it back up but only if they are needed... which many of them probably aren't.


Top
  Profile  
 
 Post subject:
PostPosted: Fri Dec 31, 2004 1:52 pm 
Bitchin' Fast 3D Z8000*
Bitchin' Fast 3D Z8000*
User avatar

Joined: Tue Jun 29, 2004 11:32 pm
Posts: 2555
Location: Somewhere between compilation and linking
Kybo_Ren wrote:
But here's the kicker:
If I minimize Azureus and wait for a bit, usage drops down to 10MB.

Does Azureus really need 30MB to draw one page? Sheesh. Must be a lot of stuff then.


It's not using 30MB to draw one page. Say you're downloading 5 files and uploading 10 - each of these files will have several buffers in memory. When a downloading file's buffer reaches the size of a disk block, it will be written to disk (and if you're downloading parts of the file from 5 people, there are probably 5 buffers for that one file). When an uploading file's buffer has been completely sent, it will be replaced by another buffer from the disk (but if there are multiple people downloading this one file it may have many of these buffers in memory). This is what is causing the memory to climb. If you leave the app minimized, the memory usage still climbs, right?

The GUI is worth about 2MB on my system. If I let the memory climb to say 30 megs and then minize, it immediately falls down to 6 megs. If I let the memory climb to 10 megs and then restore the app, it will quickly jump up about 2 megs to 12megs. If I do this several times in a row, this effect is largely minized though and the app stays close to 30 megs. The question of why the memory drops to 6 megs when the app is minized is puzzling. In general, I think that Colby's statement is correct. If you open and close or tab into windows with different gui components, there should be some overhead, and it will take a little while for the gc to run and collect them. This alone probably doesn't account for the somewhat strange behavior and large memory drops in this app though.

If I let it sit minimized long enough, it will eventually climb to over 100 megs on my system. If I restore then minimize, it falls back down to about 6 megs. If I let it climb indefintely, it will peak at about 130 megs on my system and then drop to about 30 megs, which is also very puzzling (the 6meg vs 30meg difference). Although I haven't profiled Azureus, I believe the aforementioned file buffers are not being flushed and reclaimed. They just sit in memory until the gc runs.

There is also the issue(s) of the OS caching the hard disk. Whatever the reason(s), Azureus uses a fair amount of memory - however, if you're system does get low on memory, the gc runs and the memory usage does fall substantially. It is probably just a tradeoff between hitting the disk multiple times and available memory. The nice thing about ram is that it can be reused pretty much indefinitely. :)


Top
  Profile  
 
 Post subject:
PostPosted: Fri Dec 31, 2004 4:30 pm 
Team Member Top 100
Team Member Top 100

Joined: Fri Sep 17, 2004 5:35 pm
Posts: 1176
Quote:
If you leave the app minimized, the memory usage still climbs, right?

Yeah.


However, if you watch each file as it's downloading, you'll see the data is being written to the disk very quickly. There isn't a lot of buffer usage...
It's weird. Goes fast, though :)


Top
  Profile  
 
 Post subject:
PostPosted: Sat Jan 01, 2005 1:06 pm 
Bitchin' Fast 3D Z8000*
Bitchin' Fast 3D Z8000*
User avatar

Joined: Tue Jun 29, 2004 11:32 pm
Posts: 2555
Location: Somewhere between compilation and linking
Kybo_Ren wrote:
Quote:
If you leave the app minimized, the memory usage still climbs, right?

Yeah.


However, if you watch each file as it's downloading, you'll see the data is being written to the disk very quickly. There isn't a lot of buffer usage...
It's weird. Goes fast, though :)


There could be a lot of buffers, but they're not garbage collected until sometime later. Someone would have to use a profiling tool to be sure about what is occuring though.


Top
  Profile  
 
 Post subject:
PostPosted: Thu May 05, 2005 5:21 pm 
Smithfield
Smithfield
User avatar

Joined: Sun Sep 05, 2004 9:01 am
Posts: 8091
It isn't the damn file buffers, it shoots up 50 megs+ even if your downloading one file thats 10 megs in size at 3K/sec. Plus they added buffers specifically to combat frequent disk writes, that part seems to work well and is configurable.

The problem is not in the GUI, it is not in the downloaded data. Its somewhere deeper. https://sourceforge.net/forum/forum.php ... _id=349817 - there are countless such threads on those forums and there have been for quite some time.


Top
  Profile  
 
 Post subject:
PostPosted: Fri May 06, 2005 6:18 pm 
Bitchin' Fast 3D Z8000*
Bitchin' Fast 3D Z8000*
User avatar

Joined: Tue Jun 29, 2004 11:32 pm
Posts: 2555
Location: Somewhere between compilation and linking
urmumsacow wrote:
It isn't the damn file buffers, it shoots up 50 megs+ even if your downloading one file thats 10 megs in size at 3K/sec. Plus they added buffers specifically to combat frequent disk writes, that part seems to work well and is configurable.

The problem is not in the GUI, it is not in the downloaded data. Its somewhere deeper. https://sourceforge.net/forum/forum.php ... _id=349817 - there are countless such threads on those forums and there have been for quite some time.

First, the post you linked to was just a bunch of dumbasses bitching about shit. There was not one single technical issue discussed there.

Second, how do you know it is not the file buffers?

Third, how do you know it is not the gui?

Are you qualified to or justified in ruling out these possibilities?


Top
  Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 28 posts ]  Go to page Previous  1, 2

All times are UTC - 8 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group

© 2014 Future US, Inc. All rights reserved.