Ok
I see where your coming from to a point. and maybe I am going overboard on my 
tests. I however have to disagree with prematurely optomizing. I dont know any 
thing about you or the projects you may have worked on but I have done some 
extreamly large projects where I had 28 developers working form me for over 3 
years to complete this project and not planning ahead on performance and the 
tools you use can be very detrimental to that project. for instance say you 
spent 2 years over 2 million dollars working on a project and your users now 
with millions of transactions a week and 100's of millions of records in the 
data base start to complain about the performance. throught your research into 
the defect you find that in order to solve the problem you have to replace the 
core of your application the heart of it because that core framework compoent 
has major performance issues. I am not trying to start an argument here and i 
dont want to. I am simply stateing I have been in that situation. and Before I 
commit millions of dollars on a project I think a little upfront due 
dilliagance in the core or heart of how my application will perform is 
important. YAGINI is a great concept and I mostly agree with it. but after 
years in programming. I know that rework is inevitable, but somewhat avoidable. 
That being said if you look at Microsoft and how they market one of the big 
things I see them doing is ok when we combind this technology and this one this 
is how we perform and with this one and this one we perform like this. and so 
on and so forth just look at the performance test for WCF they show every 
possible comparison to their own technologies to which one performs the best. 
now that being said there is always a trade off between performance/features 
and time. performance and features cost money. but a little planning and 
research will save tons down the road. and then at least you can find some 
middle ground. I dont intend on taking this information to move away from MR or 
AR or anything in particular. I even have webforms in the mix and I will tell 
you I can see a noticable difference between webforms and any MR view engine. 
MR way out performs WebForms. Even with my simple test. I can noticably tell 
with out taking it to a test suite. 

To that effect yes I am a little overkill on my view engine performance test. 
but in actuality I am doing more than that. I am providing a view engin 
comparison and then for each of them a comparison between the different ways of 
getting the data. so yes it is more than that but with only a few extra hours 
of codeing I think it is well worth the time spent to get the best possible 
results. and yes running the performance tests will take time. I am well aware 
of that but they is why I will start them at night and analize the next day. 

I plan on documenting allof my findings and i will put it out for eveyone to 
see and even provide the test code and db scripts to perform the tests on your 
own. One problem I always have in introducing Opensource or new technologies to 
firms is the lack of documentation or support. to back up a project like this I 
really see huge value in this. It is just marking and at the same time it is 
valueable information. People will feel more inclined to use somethign they 
find to be more powerfull and better performing. what developer doesnt hate the 
words why is this taking to long to execte Why does it take 2 seconds to save 
so little data. well it doesnt and we know that. it is the complete round trip. 

ok I am simply rambling now 
Thanks,
Terry

----------------------------------------

Return-Path: 
<grbounce-qg156quaaad3g_8ucrr-gbnnwip8nz2w=tmassey=epiphanygs....@googlegroups.com>
Received: from mail-qy0-f146.google.com [209.85.221.146] by 
mx249o.mysite4now.com with SMTP;
Thu, 14 May 2009 09:04:26 -0700
Received: by qyk10 with SMTP id 10so2211164qyk.31
for <[email protected]>; Thu, 14 May 2009 09:04:26 -0700 (PDT)
Received: by 10.224.2.130 with SMTP id 2mr442080qaj.11.1242317057754;
Thu, 14 May 2009 09:04:17 -0700 (PDT)
Received: by 10.230.2.2 with SMTP id 2gr9825vbh.0;
Thu, 14 May 2009 09:04:13 -0700 (PDT)
Received: by 10.223.112.135 with SMTP id w7mr30568fap.19.1242317052687; Thu, 14 
May 2009 09:04:12 -0700 (PDT)
Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com 
[209.85.218.161]) by gmr-mx.google.com with ESMTP id 
3si5102fgg.7.2009.05.14.09.04.12; Thu, 14 May 2009 09:04:12 -0700 (PDT)
Received: by mail-bw0-f161.google.com with SMTP id 5so1505220bwz.23 for 
<[email protected]>; Thu, 14 May 2009 09:04:12 -0700 (PDT)
Received: by 10.204.50.195 with SMTP id a3mr2276547bkg.94.1242317052421; Thu, 
14 May 2009 09:04:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=beta;
h=domainkey-signature:received:received:x-sender:x-apparently-to
:received:received:received-spf:authentication-results:received
:mime-version:content-type:content-transfer-encoding:received
:in-reply-to:references:from:date:message-id:subject:to:reply-to
:sender:precedence:x-google-loop:mailing-list:list-id:list-post
:list-help:list-unsubscribe:x-beenthere-env:x-beenthere;
bh=xQT5yKH5oopzk50scRKNdsOJbPC8q2bYg6ep3AW2GHo=;
b=1isQYRNZBYnw6SCwHSeEElBupWd0+YeenJfNHJQUf2mPbx+POztfrEIQPTNJ1td67K
skQ4AgZ/3uo2u4AflhIK5LsWF4Fkf77Wju80CogrqmfQJQDxCuB7sKobgC2wStooP9ry
PI4XASUmOshK5KBo4IGzqmn7AqYf7RpBsH6vA=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=googlegroups.com; s=beta;
h=x-sender:x-apparently-to:received-spf:authentication-results
:mime-version:content-type:content-transfer-encoding:in-reply-to
:references:from:date:message-id:subject:to:reply-to:sender
:precedence:x-google-loop:mailing-list:list-id:list-post:list-help
:list-unsubscribe:x-beenthere-env:x-beenthere;
b=oTUeKlcNkQLCdawGLAqLpdQWYV0/VDlNgbv9TMx/wB85iY2SFu/F9OFcud2qBW41um
+1wd0ZEM5P5G/SrfBSDZMNQ/C89xEqqXq/+w29pnBn3Z343qIQyQyUWABArMOojf+LkO
hI890HfDDCM2wQYSoJLzQiU8RWbd8YSeD7vwU=
X-Sender: [email protected]
X-Apparently-To: [email protected]
Received-SPF: neutral (google.com: 209.85.218.161 is neither permitted nor 
denied by best guess record for domain of [email protected]) 
client-ip=209.85.218.161;
Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 
209.85.218.161 is neither permitted nor denied by best guess record for domain 
of [email protected]) [email protected]
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <2c347061$3e0f04c6$221a47...@com>
References: <2c347061$3e0f04c6$221a47...@com>
From: Colin Ramsay <[email protected]>
Date: Thu, 14 May 2009 17:03:52 +0100
Message-ID: <[email protected]>
Subject: Re: MR View Engine Comparison
To: [email protected]
Reply-To: [email protected]
Sender: [email protected]
Precedence: bulk
X-Google-Loop: groups
Mailing-List: list [email protected];
contact [email protected]
List-Id: <castle-project-users.googlegroups.com>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]>
List-Unsubscribe: 
<http://googlegroups.com/group/castle-project-users/subscribe>,
<mailto:[email protected]>
X-BeenThere-Env: [email protected]
X-BeenThere: [email protected]
X-Rcpt-To: <[email protected]>
X-SmarterMail-Spam: Bayesian Filtering, SPF_Pass, DK_Pass
X-SmarterMail-TotalSpamWeight: 0 

I know you want to start off on the best possible footing but I think
you are trying to optimise prematurely. In my time frequenting these
lists I have *never* seen anyone complaining that the view engine is
the slow part of their application. I also think you're testing
approach is dubious, to say the least. Again, Windsor and NHibernate
have nothing to do with the view. I understand what you're saying
about pulling objects from Windsor, for example, but that's something
that could be tested independently of this View Engine Comparison.

On Thu, May 14, 2009 at 4:51 PM, Terry Massey wrote:
> What I mean by render times; I guess I was a little vague. I mean from the
> time the user makes a choice to the time the user see the result on there
> end. So yes windsor will make a difference because performing any action
> takes time. and if windsor is in the mix there is going to be time it needs
> to figure out what object is being requested and so on and so forth. and the
> reason for looking at nhibernate directly as apposed to AR I tend to have a
> feeling that it will speed up performance because I see AR having more
> Overhead. now the View I submitted is very simple and even on cassini both
> engines tested so far seem to be doing very well no noticable time
> difference. but more over I want to look more at the server what is it doing
> on there after a million or so sessions and hits to the pages does one tend
> to eat up memory what does the processor utilization look like what is the
> maximum number of requests per second each one can process. and with the the
> time to last byte. all of these things matter for an enterprise application
> and from what I see MR is more than ready for that I am just looking to get
> every last millisecond I can free up to give the user a better experience.
> Terry
> ________________________________
> Return-Path:
> 
> Received: from mail-px0-f169.google.com [209.85.216.169] by
> mx249o.mysite4now.com with SMTP;
> Thu, 14 May 2009 08:38:07 -0700
> Received: by pxi41 with SMTP id 41so544772pxi.31
> for ; Thu, 14 May 2009 08:38:06 -0700 (PDT)
> Received: by 10.140.133.10 with SMTP id g10mr407695rvd.8.1242315478211;
> Thu, 14 May 2009 08:37:58 -0700 (PDT)
> Received: by 10.106.201.4 with SMTP id y4gr9823prf.0;
> Thu, 14 May 2009 08:37:52 -0700 (PDT)
> Received: by 10.204.31.202 with SMTP id z10mr63194bkc.26.1242315471621; Thu,
> 14 May 2009 08:37:51 -0700 (PDT)
> Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com
> [209.85.218.163]) by gmr-mx.google.com with ESMTP id
> 14si7456bwz.1.2009.05.14.08.37.51; Thu, 14 May 2009 08:37:51 -0700 (PDT)
> Received: by mail-bw0-f163.google.com with SMTP id 7so1301948bwz.36 for
> ; Thu, 14 May 2009 08:37:51 -0700
> (PDT)
> Received: by 10.204.68.15 with SMTP id t15mr2227476bki.139.1242315471140;
> Thu, 14 May 2009 08:37:51 -0700 (PDT)
> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
> d=googlegroups.com; s=beta;
> h=domainkey-signature:received:received:x-sender:x-apparently-to
> :received:received:received-spf:authentication-results:received
> :mime-version:content-type:content-transfer-encoding:received
> :in-reply-to:references:from:date:message-id:subject:to:reply-to
> :sender:precedence:x-google-loop:mailing-list:list-id:list-post
> :list-help:list-unsubscribe:x-beenthere-env:x-beenthere;
> bh=76uCDbxwBIYN+4F3k+U8FqFsthZpXwBsbpPwskJhDs0=;
> b=SwtaVXb0QNYmlTDOk+eu/fd5yy0z89lY/VB3VN4N5SNox26Vn/F3prFFxiEMmPp4Vk
> SUZB78N53QQVKxGGG67PXoj7t5HeJxm/MZB06KnEH3sPEX/DaNHunwm2gl6/BF0zuAZC
> w35s41KtKKcKwZkQBEvy4JFbw6CUxpUwdODY0=
> DomainKey-Signature: a=rsa-sha1; c=nofws;
> d=googlegroups.com; s=beta;
> h=x-sender:x-apparently-to:received-spf:authentication-results
> :mime-version:content-type:content-transfer-encoding:in-reply-to
> :references:from:date:message-id:subject:to:reply-to:sender
> :precedence:x-google-loop:mailing-list:list-id:list-post:list-help
> :list-unsubscribe:x-beenthere-env:x-beenthere;
> b=kJU8QBgla5N7jDBa7PD01JqLnjMxGAVEDJDKOYZ312MFHvSKkSl3R0ksIB5G5nj6XU
> BipRYA9pzWIS71t2UJUIuiCdXITz6KR3eU54dKKWzvfD9vioHAT4jMlLJ1jiRBuuixyh
> pRUVVz3h/ubGf7fwkjpDF5pl4JakOtblcZ1t8=
> X-Sender: [email protected]
> X-Apparently-To: [email protected]
> Received-SPF: neutral (google.com: 209.85.218.163 is neither permitted nor
> denied by best guess record for domain of [email protected])
> client-ip=209.85.218.163;
> Authentication-Results: gmr-mx.google.com; spf=neutral (google.com:
> 209.85.218.163 is neither permitted nor denied by best guess record for
> domain of [email protected]) [email protected]
> Mime-Version: 1.0
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> In-Reply-To: <16ed1637$393c846a$2f9f58...@com>
> References: <16ed1637$393c846a$2f9f58...@com>
> From: Colin Ramsay 
> Date: Thu, 14 May 2009 16:37:31 +0100
> Message-ID: <[email protected]>
> Subject: Re: MR View Engine Comparison
> To: [email protected]
> Reply-To: [email protected]
> Sender: [email protected]
> Precedence: bulk
> X-Google-Loop: groups
> Mailing-List: list [email protected];
> contact [email protected]
> List-Id: 
> List-Post: 
> List-Help: 
> List-Unsubscribe:
> ,
> 
> X-BeenThere-Env: [email protected]
> X-BeenThere: [email protected]
> X-Rcpt-To: 
> X-SmarterMail-Spam: SPF_Pass, DK_Pass
> X-SmarterMail-TotalSpamWeight: -10
>
>
> How would Windsor and NHibernate have an effect on rendering times?
>
> On Thu, May 14, 2009 at 4:21 PM, Terry Massey wrote:
>> All,
>> I am working on the performance testing for the different view engines and
>> have the NVelocity and Brail views completed and configured. after looking
>> into the ASPView engine I am going to ask that those who want that one
>> completed convert the following NVelocity view to ASPView syntax. I am
>> working on the Spark Right now but I am running into a version issue where
>> the trunk build of MR and AR I am using to generate the test just is not
>> compatible. I also Plan on utilizing nhibernate and windsor as a
>> comparison
>> test as well to see the performance impact they have on render response
>> times. for ASPView I may also need some assistance in configuration as I
>> have yet to implement anything with that engine.
>>
>> <
>>
>> h3>Accounts list
>
>>
>>
>> Account Code
>> LevelID
>> Account Desc
>> Active
>>
>> #foreach($Account in $Accounts)
>>
>> $Account.AccountCode
>> $Account.LEVELID
>> $Account.AccountDescription
>> $Account.ACTIVE
>>
>> #end
>>
> Thanks,
>> Terry Massey
>>
>>
>> ------------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>>
>>
>> I'm interested as well
>>
>> Juan Carlos Seguí
>> Dpto. I+D+i - CAE, S.A.
>>
>> San Francisco de Borja, 18
>> 46701 Gandía. Valencia.
>>
>> www.cae.net
>> +34 962 872 010
>>
>> Terry Massey escribió:
>>
>> I agree that there isn't much time spent in the view engine but every ms
>> counts on a enterprise site. when you have complex logic that must occur
>> and
>> the choice for a view engine is interpreted and takes an extra 10 ms that
>> could be used else  where for more complex logic it is well worth it to
>> consider this. I have spent too much time on past projects trying to find
>> ways to enhance performance to find that the big stumbling block was the
>> backend dll's i had no control over. While MR provides so much more
>> control
>> over what is rendered and the wonderful end to Viewstate. I still want to
>> make sure at this point in my project I am picking the best performing
>> tools
>> for the job. with a balance on the tells and technologies I wish to link
>> up
>> with and utilize. and the castle project provides that but the View engine
>> is a plugable piece that I really want to make sure isn't going to be a
>> plug
>> in the flow.
>>
>> I will do something then If any one is interested I will share my results
>> I
>> will put together a series of simple views reading lists of data from a
>> single db on a single server and do some benchmark of my own. if
>> interested
>> I will post my results with the tested views used. I may ask for some help
>> once I get the NVelocity views complete. to make sure I am utilizing the
>> other engine syntax correctly.
>>
>> I will even create a asp.net webforms to compete it against. if there is
>> enough interest.
>>
>> Please let me know if there is interest in this type of performance data.
>>
>> Thanks,
>> Terry Massey
>>
>>
>>
>> >
>>
> >
>


 

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Castle Project Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/castle-project-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to