Hello,
Paolo Molaro wrote:
All of that is fine, except that you get incorrect data, since we have arrays
of shorts or ints, so we either give incorrect results on bigendian systems
or we introduce code to byteswap at runtime, needlessly slowing down the code.
The code should do what we already
Hello,
Paolo Molaro wrote:
On 07/24/05 Miguel de Icaza wrote:
It can be done in two ways: embed the files in the mono binary like we do
with the char tables or load the files from where mscorlib was loaded.
Both are trivial to implement.
For now I took the latter approach. That means however
On 07/24/05 Miguel de Icaza wrote:
> > > It can be done in two ways: embed the files in the mono binary like we do
> > > with the char tables or load the files from where mscorlib was loaded.
> > > Both are trivial to implement.
> >
> > For now I took the latter approach. That means however we nee
Hey!
> http://monkey.workarea.jp/tmp/20050725/prof-no-collation.txt
> http://monkey.workarea.jp/tmp/20050725/prof-managed-collation.txt
>
> --- no-collation ---
> Time(ms) Count P/call(ms) Method name
> 41982.000 102284.105 Mono.CSharp.Block::Resolve(EmitContext)
> Total memory allocate
Hello,
> Notice that I suggested "GetManifestResourceInternal", not the similarly
> named "GetManifestStream". The managed collaction code uses a Stream
> interface.
>
> What am suggesting is that instead of adding a new icall whose purpose
> is to return an IntPtr + the size of a special-cased
Hello,
> > I personally like the idea of having this data on the dll files
> > themselves more, you can embed the resources with -resource and then get
> > the same IntPtr without adding a new icall like this:
> >
> > int size;
> > Module module;
> > IntPtr data = GetManifestResourceInternal (nam
Hello,
>>I measured the performance for mcs.exe build and put the results
>>here:
>>http://monkey.workarea.jp/tmp/20050720/prof-no-collation.txt
>>http://monkey.workarea.jp/tmp/20050720/prof-managed-collation.txt
>
>
> Thanks for posting these profiles, this is done with
> USE_MANAGED_RESOURCE?
Hello,
>>>It can be done in two ways: embed the files in the mono binary like we do
>>>with the char tables or load the files from where mscorlib was loaded.
>>>Both are trivial to implement.
>>
>>For now I took the latter approach. That means however we need some
>>love on the build system.
>
>
Hello,
> I measured the performance for mcs.exe build and put the results
> here:
> http://monkey.workarea.jp/tmp/20050720/prof-no-collation.txt
> http://monkey.workarea.jp/tmp/20050720/prof-managed-collation.txt
Thanks for posting these profiles, this is done with
USE_MANAGED_RESOURCE?
Also, I
Hello,
> > It can be done in two ways: embed the files in the mono binary like we do
> > with the char tables or load the files from where mscorlib was loaded.
> > Both are trivial to implement.
>
> For now I took the latter approach. That means however we need some
> love on the build system.
I
Atsushi Eno wrote:
The attached patch expects those collation.*.bin files to be in
the same directory as mscorlib.dll exists.
One thing I'd note is that I could *not* build the path to those
files - I tried the same way as mono_init_internal() does to load
mscorlib.dll, but it messed NUnit test
Hello,
Paolo Molaro wrote:
It can be done in two ways: embed the files in the mono binary like we do
with the char tables or load the files from where mscorlib was loaded.
Both are trivial to implement.
For now I took the latter approach. That means however we need some
love on the build syste
On 07/21/05 Ben Maurer wrote:
> On Fri, 2005-07-22 at 12:53 +0900, Atsushi Eno wrote:
> > + class UnmanagedMemoryStream : Stream {
> > unsafe byte *base_address;
> > - int size;
> > - int position;
> > + long size;
> > + long position;
>
> It's
On 07/22/05 Atsushi Eno wrote:
> Well, 180KB is about only one file. Though today I optimized that
> 180 KB file to 120 KB, there are additional files that are up to
> 220KB (all *.bin files in http://monkey.workarea.jp/tmp/20050720/ )
I know, but it's fine: most people could esily remove them and
Hi,
Ben Maurer wrote:
> On Fri, 2005-07-22 at 12:53 +0900, Atsushi Eno wrote:
>
>>+ class UnmanagedMemoryStream : Stream {
>> unsafe byte *base_address;
>>- int size;
>>- int position;
>>+ long size;
>>+ long position;
>
>
> It's
On Fri, 2005-07-22 at 12:53 +0900, Atsushi Eno wrote:
> + class UnmanagedMemoryStream : Stream {
> unsafe byte *base_address;
> - int size;
> - int position;
> + long size;
> + long position;
It's a bit more efficient so store those
Hi,
>>>Managed resources are loaded as an IntPtrStream. Inside corlib, you can
>>>cast to that type and get the IntPtr (possibly adding a call to do
>>>that).
>>
>>Is that cast really kind of thing on that I can depend?
>
>
> Yes, sorta. We need to change this class to be called
> UnmanagedMemor
On Fri, 2005-07-22 at 03:51 +0900, Atsushi Eno wrote:
> Hi,
>
> Ben Maurer wrote:
> > On Fri, 2005-07-22 at 03:18 +0900, Atsushi Eno wrote:
> >
> >>So, you mean, I should avoid managed resource but acquire those
> >>pointers from the runtime via icall, right?
> >
> >
> > Managed resources are l
Hi,
Ben Maurer wrote:
> On Fri, 2005-07-22 at 03:18 +0900, Atsushi Eno wrote:
>
>>So, you mean, I should avoid managed resource but acquire those
>>pointers from the runtime via icall, right?
>
>
> Managed resources are loaded as an IntPtrStream. Inside corlib, you can
> cast to that type and g
On Fri, 2005-07-22 at 03:18 +0900, Atsushi Eno wrote:
> So, you mean, I should avoid managed resource but acquire those
> pointers from the runtime via icall, right?
Managed resources are loaded as an IntPtrStream. Inside corlib, you can
cast to that type and get the IntPtr (possibly adding a call
Hello,
180 KB is reasonable for now. It would be good to be able to
build a configuration that allows just simple us-ascii collation
for embedded systems that really care.
We can look at optimizing the size when the speed issues are sorted out.
Well, 180KB is about only one file. Though today
On 07/21/05 Atsushi Eno wrote:
> > It'd be nice to optimize the format *before* we check in the binary
> > files, since optimizing will require some frequent changes.
>
> As the quality of data storage, yes they could be made smaller.
> The table could be much smaller even if I introduced simple
>
Atsushi Eno wrote:
> I can build mcs with this managed collation mode and all corlib
> tests pass (I guess other tests as well).
>
> When this managed collation is enabled, it will eat huge managed
> resource (and will make you sad when you run mono --profile ;-).
> I can make this into unmanaged
Hola Opti-Ben,
Ben Maurer wrote:
> Some messages from your neighborhood optimizer :-).
Thanks ;-)
> Some things I noticed while viewing the files in a hex editor:
>
> * There are extremely long runs of the same char in many instances
> * The file seems to have tons of 0 bytes.
>
Some messages from your neighborhood optimizer :-).
On Thu, 2005-07-21 at 02:12 +0900, Atsushi Eno wrote:
> Hello,
> But besides the patch, I need to checkin 7 prebuilt binary resource
> files in mcs/class/corlib directory, though they can be built when
> you run "make" in mcs/class/corlib/Mono.Gl
I forgot to mention what this patch fixes, on String.cs and
CompareInfo.cs.
String.cs : The length of compared string might not be equal
to another one, so we should not use the length of "value"
in IsPrefix().
CompareInfo.cs : It switches between managed collation and
unmanaged one (not working
Hello,
I think it could be the time to merge my managed collation patch
that enables Windows like collation at managed code side.
** The changes I want to make
The attached patch. Actually it is already in svn:
mcs/class/corlib/Mono.Globalization.Unicode/managed-collation.patch
But besides the
27 matches
Mail list logo
