Lloyd Bryant wrote:
> FYI- I'm currently testing some more changes in share.c, but not related to 
> the sort (I spotted some weirdness in recurse_scan_intern(), such as the 
> fact that it was stat'ing or lstat'ing each file a total of three times, 
> which I thought was a bit silly.).  I'll post something when I have it 
> adequately tested.

You can probably easily get rid of the stat() in the loop over files and
also get rid of this list. Directories should be put into a list just
as it happens now but regular files should be handled immediately.
 
> After restructuring things a bit, I think I see a place where we can load 
> the SHA1's from cache well before the sort.  I still need to think about 
> that, though, as without a valid sf->file_index, I'm not sure this is going 
> to be much use.

I've simplified huge.c, so that it doesn't use sf->file_index anymore. So
the index could be changed before but also after request_sha1().

> Question (if anyone knows): Is there a reason that shared_file carries the 
> SHA1 as part of the structure, rather than a pointer to the sha1_cache 
> entry?  At first glance that looks like a good way of linking the two, but I 
> haven't dug deeply enough into other parts of the program to know if there 
> are reasons for the isolation.

I don't see any reason why it has to be one way or another but not linking
those is probably simpler. After my current changes you wouldn't safe any
memory because both use a SHA-1 atom. You could save some memory if you used
mtime, filename and filesize from the shared_cache_entry. On a 64-bit arch,
you'd save 24 bytes of memory per shared file.

-- 
Christian

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Gtk-gnutella-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

Reply via email to