[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Re: [zzdev] The speed hog...
- To: "B. Fallenstein" <b.fallenstein@xxxxxx>, ZZ Development <zzdev@xxxxxxxxxx>
- Subject: Re: [zzdev] Re: [zzdev] The speed hog...
- From: Tuomas Lukka <lukka@xxxxxxxxxx>
- Date: Mon, 17 Sep 2001 12:52:23 +0300
- In-reply-to: <20010916230335.E7993@xxxxxxxxxxxxxx>; from lukka@xxxxxxxxxx on Sun, Sep 16, 2001 at 11:03:35PM +0300
- Mail-followup-to: "B. Fallenstein" <b.fallenstein@xxxxxx>, ZZ Development <zzdev@xxxxxxxxxx>
- References: <3BA3E932.1BF908F@xxxxxx> <20010916205003.D7993@xxxxxxxxxxxxxx> <20010916230335.E7993@xxxxxxxxxxxxxx>
The most important result from profiling loading currently is
[17] 11.1 0.04 0.52 14888 org::gzigzag::impl::BlockedVStreamDim::getBlock(java::lang::String *, JArray<int> *) [17]
0.23 0.00 1155436/1155724 org::gzigzag::impl::unsigned BlockedVStreamDim_0024Block::contains(int) [68]
0.01 0.18 13231/28914 java::lang::Integer::parseInt(java::lang::String *) [33]
In plain language, this means that getBlock is called 14888 times
and it, in turn, calls Block::contains all of 1155436 times(!!!).
That's about 100 blocks per transclusion. This means that we need to have
a better data structure, as this is currently eating about 5-10% of the load
time.
Benja: how far from working is LinkedVStreamDim?
Tuomas