[jcifs] Re: SMB URL encoding/decoding

[rjw]

Mike,

We've been running our app through OptimizeIt lately. 5% of all String's 
are created in one function: SmbURL.parseURL()!

If you're writing an application that does a lot of crawling, then, I 
agree that listFiles() is going to obviate the need for the constructor 
I'm talking about. But if you're doing a lot of SmbFile creations 
outside of listFiles, I think it'd be really nice to have an alternate 
method of creating them that bypasses SmbURL.parseURL().

If it's already there, just make it public! =)

> 	I don't see why this is really necessary for reasons described above. I would
> 	rather remove the cause of the problem rather than add something to mask it.

I disgree that the cause of the problem is gone. The cause of the 
problem is that Strings in Java really bite, as you said. anything we 
can do to minimize the creation and garbage collection of these, the better.

> 	There's definitely some improvement that can be done here. I don't know if
> 	you've been following the other posts in this thread but the conclusion was
> 	that the current SmbURL handling is just wrong. The correct method is
> 	actually much easier. As a result I think the code will be more streamlined. It
> 	should probably manipulate char[] rather than using charAt and substring
> 	which will prevent a few unnecessary String objects from being created for
> 	each URL parse.

I've been following this thread with a great amount of interest. I think 
it's very important that we nail down the proper behaviour. And while I 
agree that optimizing that routine and making it spec compliant are both 
great, the best optimzation you can ever make to a function is to skip 
calling it. ;)
> 
> 	We might also consider the intern() method of String. 

Interning might help, especially under load... it all depends on the 
number of common strings, which depends on usage, really. if all of the 
user's are accessing files in a very tight and deep structure interning 
will help more than if it's a very flat structure. That seems like a 
good thing, but not necessarily the low-hanging fruit.

>>I'm not saying we should do away with the SmbURL constructor -- it's 
>>very handy -- but maybe we should support both.
 >> 	There is no SmbURL constructor. SmbURL.parseSmbURL is static at the
> 	moment. But it might just disappear entirely.

I should be more clear. The SmbURL constructor of SmbFile. =)

/rjw
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3229 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.samba.org/archive/jcifs/attachments/20020225/1ffc8213/smime.bin