Path: news.mathworks.com!not-for-mail
From: "Jveer " <jveer@jveer.com>
Newsgroups: comp.soft-sys.matlab
Subject: Re: please help optimize this ('find' is too slow)
Date: Tue, 9 Dec 2008 04:06:02 +0000 (UTC)
Organization: University of Manchester
Lines: 47
Message-ID: <ghkqra$pq9$1@fred.mathworks.com>
References: <gh46f4$pg2$1@fred.mathworks.com> <gh7ror$eno$1@fred.mathworks.com> <gh7vs8$fgq$1@fred.mathworks.com> <gh9faq$fb4$1@fred.mathworks.com> <gh9qmi$l5c$1@fred.mathworks.com> <gh9ske$6he$1@fred.mathworks.com> <gha1vj$850$1@fred.mathworks.com> <ghefbe$ell$1@fred.mathworks.com> <gher83$sfd$1@fred.mathworks.com> <ghfk6p$mu6$1@fred.mathworks.com> <ghi6f9$3um$1@fred.mathworks.com>
Reply-To: "Jveer " <jveer@jveer.com>
NNTP-Posting-Host: webapp-02-blr.mathworks.com
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Trace: fred.mathworks.com 1228795562 26441 172.30.248.37 (9 Dec 2008 04:06:02 GMT)
X-Complaints-To: news@mathworks.com
NNTP-Posting-Date: Tue, 9 Dec 2008 04:06:02 +0000 (UTC)
X-Newsreader: MATLAB Central Newsreader 1206797
Xref: news.mathworks.com comp.soft-sys.matlab:505767


hello Roger

thank you for the continued support. i apologise for not responding sooner. 

well the sort worked miracles on the original version. it brought down the processing time on a sample data from 28s to 13s. Additionally, I've broken down all the & and replaced them with if ~isempty to mimick the &&. The profiler results on the sample data posted on http://idisk.mac.com/jveer-Public?view=web of the latest version of the code based on your recommendations were very satisfying. The processing time went down from 170s to 42s!

the latest code is as follows:

load SampleData.mat NCx NCy NCz P

m=length(NCx(:,1));
if m<=32767,PiC=zeros(1,length(P),'int16');
else PiC=single(zeros(1,length(P)));end

% Uy=max(NCy,[],2)';Ly=min(NCy,[],2)';Uz=max(NCz,[],2)';Lz=min(NCz,[],2)';
Ux=max(NCx,[],2)';Lx=min(NCx,[],2)';
[t,r]=sort([Lx,Ux,P(1,:)]);s=1:length(r);s(r)=s;

% Simulataneously findind all Material Points that could be in cell c using
% the x,y and z limits of the cell
for c=1:m% For each cell
    nx=r(s(c):s(c+m));nx=nx(nx>2*m)-2*m;
    if ~isempty(nx);
        ny=nx(P(2,nx)>=min(NCy(c,:)));
        if ~isempty(ny)
            ny=ny(P(2,ny)<max(NCy(c,:)));
            if ~isempty(ny);
                nz=ny(P(3,ny)>=min(NCz(c,:)));
                if ~isempty(nz)
                    nz=nz(P(3,nz)<max(NCz(c,:)));
                    if ~isempty(nz);
                        PiC(nz)=c;
                    end
                end
            end
        end
    end
end

Your new idea sounds very promising. I'm afraid i have no idea how to put that into code though. i reckon as long as the sort is outside the loop it'll be fine. it 0.09s on the sample data i used. profiler results .tiff can be found on the link above. i know it's a lot to ask but any chance you could put that into code?



"Roger Stafford" <ellieandrogerxyzzy@mindspring.com.invalid> wrote in message <ghi6f9$3um$1@fred.mathworks.com>...
> "Roger Stafford" <ellieandrogerxyzzy@mindspring.com.invalid> wrote in message 

>   Perhaps I surrendered too soon in that previous article, Jayveer.  A method has occurred to me that would first require doing the kind of sorting I previously mentioned three times rather than one time, once for each coordinate direction.  That is, there would be three sorts done just one time each for a given run which look like this: