[ossrp-control] Re: So, where do you want the project to go?

Hi Jamal,

Yes it will be slower, but not as much as people often think.  Imagine you
have a function called foo.  When you run the program and first call foo, it
is in intermediate code, but needs to be converted to native code in order
to be run.  However, after the first conversion, the native code for foo is
stored in the CLR, so any subsequent calls to foo don't have to under go
that conversion to native code, which is currently what non-.Net code
compiles to.  There's the garbage collector that runs in the background, but
this runs on it's own thread and won't degrade application performance,
although it does very slightly degrade system performance.

Personally, I don't think system performance is the big worry that it is
often made out to be.  Unless something is extremely slow, and noticeably
so, the experience is that people aren't bothered about it so much.  I once
ran a profiler on an old DOS program that I built in the mid 90's.  98% of
the time was spent in user input sections, and most of that wasn't spent
processing anything, but awaiting user input.  So, to achieve the best
performance, the user interface of an application should be optimised for
semantics, interaction model and ergonomics before the efficiency of the
code is worried about.

Will
----- Original Message ----- 
From: "Jamal Mazrui" <Jamal.Mazrui@xxxxxxx>
To: <ossrp-control@xxxxxxxxxxxxx>
Sent: Monday, April 25, 2005 11:15 PM
Subject: [ossrp-control] Re: So, where do you want the project to go?


> I agree that a well coded .NET program can outperform a poorly coded
> program in an unmanaged language.  Assuming equivalent programs are
> professionally coded, however, I think the .NET one will be noticeably
> slower.  That is not necessarily bad overall because performance is not
> the only valid consideration, e.g, others may be stability,
> maintainability, and scaleability. =20
>
> Where performance is the highest priority though, such as in
> system-level services, I doubt that a .NET language would be preferred.
> The .NET framework itself, for example, is probably written in C or
> Assembler, and probably still makes calls to the Win32API, which, as I
> understand it, Microsoft will have to keep under the hood for backwards
> compatibility for years to come.
>
> Regards,
> Jamal
>
> -----Original Message-----
> From: ossrp-control-bounce@xxxxxxxxxxxxx
> [mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of David Lant
> Sent: Monday, April 25, 2005 5:26 PM
> To: ossrp-control@xxxxxxxxxxxxx
> Subject: [ossrp-control] Re: So, where do you want the project to go?
>
>
> And in fact, many unmanaged languages are more interpreted than many =3D
> people
> think.  VB6, for example, is not entirely compiled, hence the need for a
> =3D
> VB
> runtime which does perform partial interpretation.
>
> Personally, I would imagine most performance problems that your average
> =3D
> end
> user can notice, are mainly down to poor design or coding practice.  =3D
> Because
> many complex and common features are directly provided or supported by =
> =3D
> the
> CLR and the .NET Framework, you can actually obtain performance benefits
> under .NET, which otherwise would have had to be hand cranked before.
>
> Basically, design the system to load and compile the components you =3D
> *know*
> will be needed most up front.  Then let the CLR handle it from there, as
> long as you don't code humongous modules from which you're only invoking
> =3D
> a
> couple of lines. <smile>  Modularise sensibly.
>
> All the best,
>
> David
>
>
> -----Original Message-----
> From: ossrp-control-bounce@xxxxxxxxxxxxx
> [mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of Will Pearson
> Sent: 25 April 2005 06:42
> To: ossrp-control@xxxxxxxxxxxxx
> Subject: [ossrp-control] Re: So, where do you want the project to go?
>
>
> Hi Jamal,
>
> Yes, there's a slight performance hit with .Net languages at the moment.
> This is to do with the need to compile the code from an intermediate
> language to the native instruction set when each element of the program
> =3D
> is
> run for the first time each time the program is run.  So, the =3D
> performance
> hit isn't great on elements of the program that are used frequently.  =
> =3D
> There
> are ways to get around this, such as ngen, but performance is probably
> impacted more by design than whether it's native or intermediate code.
>
> Will
> ----- Original Message -----=3D20
> From: "Jamal Mazrui" <Jamal.Mazrui@xxxxxxx>
> To: <ossrp-control@xxxxxxxxxxxxx>
> Sent: Monday, April 25, 2005 4:39 PM
> Subject: [ossrp-control] Re: So, where do you want the project to go?
>
>
> > I agree that a .NET based screen reader would offer a benefit in=3D20
> > portability to other operating systems that also have .NET support.
> =3D20
> > My concern would be performance, as I've noticed that .NET=3D20
> > applications seem to run more slowly than others, presumably
> because=3D20
> > of their more interpreted nature and use of a runtime engine.
> >
> > Regards,
> > Jamal
> >
> >
> > -----Original Message-----
> > From: ossrp-control-bounce@xxxxxxxxxxxxx
> > [mailto:ossrp-control-bounce@xxxxxxxxxxxxx] On Behalf Of Will Pearson
> > Sent: Sunday, April 24, 2005 3:04 PM
> > To: ossrp-control@xxxxxxxxxxxxx
> > Subject: [ossrp-control] Re: So, where do you want the project to go?
> >
> >
> > Hi Ryan,
> >
> > Point noted.  If we do go down the route of using the .Net
> Framework=3D20
> > and a component based architecture, it should only take two of some of
> =3D
>
> > the components to have things working on 98SE, 2000 and upwards. =3D20
> > Whether this
> > is architecturally possible in terms of the software design is =3D
> something
> > that would have to be investigated, but it's something that will
> > certainly
> > be looked into.
> >
> > Will
> > ----- Original Message -----=3D3D20
> > From: "Ryan Mann" <rmann@xxxxxxxxxxxx>
> > To: <ossrp-control@xxxxxxxxxxxxx>
> > Sent: Saturday, April 23, 2005 7:58 PM
> > Subject: [ossrp-control] Re: So, where do you want the project to go?
> >
> >
> > > Hello.  I have a suggestion about the screen reader you plan to
> > develope
> > > for Longhorn.  That is, that it is also made to be compatible with
> > Windows
> > > XP.  I make this suggestion because you say that you want to make
> > access
> > > technology affordable to everyone.  One way to do this is to make it
> > work
> > > with operating systems that people already have on their computer.
> =3D20
> > > On
> > the
> > > otherhand, if you only make it compatible with the latest =
> Windows=3D20
> > > operating system, people will have to spend money to purchase
> that=3D20
> > > operating system in order to use your screen reader.  I've recently
> > gotten
> > > a laptop computer with Windows XP and I don't think I could justify
> > buying
> > > a new operating system in order to try out a particular screen=3D20
> > > reader. Out of curiosity, is there going to be some special
> feature=3D20
> > > in Windows Longhorn that makes it easier to develope screen
> readers=3D20
> > > for it?  I'm
> > just
> > > wondering why you want to develope the screen reader just for=3D20
> > > Longhorn
> > and
> > > not operating systems that people already have installed on =
> their=3D20
> > > computers. just my opinion.
> > > Ryan
> > >
> > >
> > > On Sat, 23 Apr 2005, Will Pearson wrote:
> > >
> > > > Hi,
> > > > As the OSAT Project is a community project, it's vital that
> you,=3D20
> > > > the
> > community, get involved in determining the direction the project
> goes=3D20
> > in. So, we're throwing the floor open to discussion on what you
> would=3D20
> > like to
> > see happen in the world of access technology research and development.
> > The
> > only thing that we ask, is that all suggestions are in-line with the
> > goals
> > of the project: 1) To advance the state of the art in access =3D
> technology
> > research and the abilities it provides it's users, and 2) to provide
> > those
> > who cannot currently afford access technology with the abilities that
> =3D
> it
> > brings to people.
> > > >
> > > > Some of the ideas that we've had so far are:
> > > > 1. A screen reader for Windows Longhorn, which I'll explain more
> > about
> > in a separate message.
> > > > 2. An OCR system for dealing with hand writing and other text.
> 3.=3D20
> > > > An auditory synthetic vision system.
> > > >
> > > > We'll likely not have the resources to work on everything everyone
> > wants
> > at once, but make suggestions.  If you can, try to explain how =
> they=3D20
> > would fit in with the project's goals, and we'll take the
> discussion=3D20
> > from there.
> > > >
> > > > Thanks,
> > > >
> > > > Will
> > > >
> > > >
> > >
> > >
> >
> >
> >
> >
> > To post to the list, send a message to: ossrp-control@xxxxxxxxxxxxx
> > To unsubscribe, send a message to:
> > ossrp-control-request@xxxxxxxxxxxxx
> > and set the subject field of the message to "unsubscribe" (without the
> quotes
> >
> >
>
>
> To post to the list, send a message to:
> ossrp-control@xxxxxxxxxxxxx
> To unsubscribe, send a message to:
> ossrp-control-request@xxxxxxxxxxxxx
> and set the subject field of the message to "unsubscribe" (without the
> quotes
>
> To post to the list, send a message to:
> ossrp-control@xxxxxxxxxxxxx
> To unsubscribe, send a message to:
> ossrp-control-request@xxxxxxxxxxxxx
> and set the subject field of the message to "unsubscribe" (without the
> quotes
>
>
> To post to the list, send a message to:
> ossrp-control@xxxxxxxxxxxxx
> To unsubscribe, send a message to:
> ossrp-control-request@xxxxxxxxxxxxx
> and set the subject field of the message to "unsubscribe" (without the
quotes
>
>


To post to the list, send a message to:
ossrp-control@xxxxxxxxxxxxx
To unsubscribe, send a message to:
ossrp-control-request@xxxxxxxxxxxxx
and set the subject field of the message to "unsubscribe" (without the quotes

Other related posts: