Loading user information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading user information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements


glebd glebd Turning coffee into code
  • Windows 7 Ideas

    I think most of you are missing the point. As I read your suggestions (except maybe for one that suggested rewriting from scratch), the expression "polishing the turd" comes to mind. If Microsoft doesn't rewrite the whole thing and gets rid of all the compatibility crud (perhaps by virtualising it), Windows is doomed. Think about it: Vista code base is 40% bigger that XP code base (an unconfirmed quote from somewhere online) -- there is no way you can turn this to an advantage! There is a good article somewhere on the nets comparing Vista to dBASE IV (hint: compatibility killed it). The problem is, though, that at the moment compatibility is all that Windows has. If people had to choose between, say,  Windows-2010-Without-Backward-Compatibility and other OS, they'd probably keep running XP forever (in enterprise) or switch to Mac or Linux (at home). Make your own conclusions.

  • The silence is broken! (IE8)

    I find it strange and even suspicious that Billg doesn't know (or is pretending not to know) what is happening in the team that produces one of the most important MS products. Talk about non-transparency...

  • Poor performance of .NET Regex

    AdrianJMartin wrote:
    one huge difference is that the body of text you are searching will have been pushed into unmanged memory...

    Not really, as the text is split into lines first in the C# program before matching each line with regex. So I don't think managed/non-managed memory difference comes into play here.

    The only difference in the code was that the initial version used Regex.Match(), and the new version uses PCRE wrapper function to do the same on the same strings using the same regular expression. The surrounding code is absolutely the same. The difference in speed must be in the way regular expressions are implemented in PCRE and .NET.

  • Poor performance of .NET Regex

    JohnnyAwesome wrote:
    Are you able to post any code samples with the difference between implementation of your compiled C# RegEx class and your wrapper call?

    Unfortunately no, as all of this code is client-owned. However, I only used simple matching, there is nothing fancy there.

  • Poor performance of .NET Regex

    JChung2006 wrote:
    Did you use a compiled or uncompiled regular expression in your C# version?

    Tried both, couldn't notice any significant difference. That's when I pre-compiled the Regex object into a DLL (which didn't help either, quite surprisingly.)

  • Poor performance of .NET Regex

    Recently in a C# application I was writing I had to process quite a few lines of text using regular expressions (many thousands). Initially I used .NET Regex class for that. The processing of the entire amount of data took a little longer than 4 minutes on a P4 3 GHz machine (Windows XP Professional.) After profiling I saw that most of the time (99%) was spent in Regex.Match() function. I tried to pre-compile the Regex object into a separate DLL to improve speed but it did not produce noticeable difference, the whole amount of data still taking about 4 minutes to process.

    Not satisfied with this (we had to go through the whole process quite often and it was very bothersome), I downloaded a Windows port of PCRE C library (Perl Compatible Regular Expressions, http://www.pcre.org/). I then produced a very thin managed wrapper around the plain C API of that library using C++/CLI, and called the wrapper from my C# application, replacing  Regex.Match() with the appropriate PCRE function. The regular expression, however inefficient it may have been (I'm no regex expert), stayed the same.

    The next time I ran the application with a stopwatch, I couldn't believe my eyes. The whole data processing took... wait for it... 8 SECONDS!

    So, using the same regular expression and the same data: .NET Regex: 4 minutes, PCRE wrapped in C++/CLI: 8 seconds.

    Can anyone explain this kind of difference? Is PCRE a miracle? Or, more likely, is .NET Regex implementation really THAT bad?

  • So .NET is ​"​Resource&qu​ot; Sourced... what's next?

    ScanIAm wrote:
    I'm sure there were some lawyers involved in this decision, but if you limit your developer pool to people who know .Net and haven't ever felt the desire to take a look at how it works, then you might not have the best developers to choose from

    Well, you surely would not get those who like to copy-paste their code.

    Seriously, are you sure .NET source code is all rosy? I bet they had to clean it up quite a bit before releasing for everyone to see, if the previously leaked Windows 2000 code is any indication (I haven't seen it, just read this review).

    From the initial announcement, a snippet of commented .NET source:
    finally {
        // restore culture
        RestoreCultures(currentThread, prevCulture, prevUICulture);

  • 7.4.3.....​holy cr@p Apple!!!

    CannotResolveSymbol wrote:
    glebd wrote:
    Harlequin wrote:
    ANOTHER iTunes update. ANOTHER 55MB. Does Apple not know how to apple patches or something?

    I take it you are equally annoyed by Microsoft's "patch Tuesdays"?

    The point here is that Apple doesn't patch.  They send down the whole installer and reinstall the product, all 55 MB of it.

    That's rather large for a point release.

    If you release a product and then keep patching it instead of updating as a whole, you end up with an unmanageable mess. It is much easier in the long run to release a complete update than keep supporting various patch combinations and make sure they all work together. Hint, hint...

  • 7.4.3.....​holy cr@p Apple!!!

    Harlequin wrote:
    ANOTHER iTunes update. ANOTHER 55MB. Does Apple not know how to apple patches or something?

    I take it you are equally annoyed by Microsoft's "patch Tuesdays"?

  • So .NET is ​"​Resource&qu​ot; Sourced... what's next?

    thumbtacks2 wrote:
    It would be a silly if Mono doesn't hire you because of "seeing the source code". That's their own choice, though, and I can see the legal issues they are trying to avoid.

    Remember SCO (there was a company named SCO once, and it was even listed)? They suddenly decided that Linux contained code infringing on their ©.

    If a code snippet appears in Mono that is similar to .NET code and there are Mono contributors who had seen the .NET code, MS potentially may want to shut down Mono or do something else along the lines.

    Now, given SCO current status, they may want to think twice about that, but still the possibility remains. I guess that's why Mono guys are being careful about this.