Slashdot Mirror
NetBeans 7.0 Is Now Available
An anonymous reader writes "Oracle releases NetBeans IDE 7.0, which introduces language support for development to the proposed Java SE 7 specification with the JDK 7 developer preview. The release also provides enhanced integration with the Oracle WebLogic server, as well as support for Oracle Database and GlassFish 3.1. Additional highlights include Maven 3 and HTML5 editing support; a new GridBagLayout designer for improved Swing GUI development; enhancements to the Java editor, and more."
Need a feature comparison grid.
with NetBeans 7 with maven3, nexus and Hudson, you could put them to shame any day.
disclaimer
I used to be a sun campus evangelist
Jehovah be praised, Oracle was not selected
It can do Java out of the box. :-P
But in all seriousness, add the right plugins and wait for it to load and Eclipse will blow everyone out of the water.
Visual Studio can work with Java projects? If you want to use the Microsoft vertical stack, then stick with Visual Studio. Netbeans supports several application stacks -- many use it just for it's comprehensive PHP support.
The wheel is turning, but the hamster is dead.
we are talking about NetBeans, if you are mavenized NetBeans is leaps and bounds ahead of eclipse.
Jehovah be praised, Oracle was not selected
Both Visual Studio 2010 and NetBeans 7 allow enterprise developers to create and deploy enterprise frameworks for the enterprise, then develop enterprise software solutions with re-usable enterprise components while reading enterprise documentation.
Enterprise.
There's no -1 for "I don't get it."
The word you want is concede, not conceive.
which is totally what she said
I like vi. I like NB. Been using it since it was Forte - so much less-bloated than Eclipse. Kudos NB Team and please keep it up.
Website Hosting
I use this on a daily basis for PHP projects. Haven't found anything that comes close to saving me time and guessing what I'm trying to do correctly as I'm typing. It's very smart when you mix HTML, CSS, PHP and Javascript as well.
It's pretty bad when you have to evangelize a campus ;)
Sorry, but on a related note, I've generally been impressed with NetBeans prior versions but they never picked up as much support as Eclipse did for plugins so I've been sticking with Eclipse. I think the last time I checked out NetBeans was when I wanted to fiddle with the Ruby plugin. Hopefully 7 will impress me before I end up removing it later. ;)
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
I wouldn't know how Visual Studio is these days, but some developers I know say that Eclipse beats VS2010 in most respects. I do now Eclipse and Netbeans fairly well and I'd say that Eclipse out-of-the-box is nothing compared to netbeans. With plugins they are comparable, but the GUI builder of Netbeans beats all the ones I've used so far. Also the Maven integration is much better in Netbeans than Maven. So it depends on what features you want to show tour coworkers and I'd say give it a try.
You do realize your co-workers would be able to run this under Windows as well right?
Damn, I finally thought I was going to "get some" by evangelizing.
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
Thanks.
What's Hudson? I've never heard of it. I've heard of Jenkins, though. ;)
Was anyone able to follow the OPs stream of thought? I feel like I lost some cells just reading it.
Eclipse is demanding of CPU and memory. That does not make it a bad editor.
It works for the Mormons.
I'm surprised that Swing is still being developed. It seems like they should just add SWT to the official spec...it looks better, performs better, and seems to be much more popular among developers of nontrivial Java GUI programs. Granted they'd need to add a fallback for unusual platforms with no native widgets to use, but that should be relatively small compared to the overall work needed.
I think you missed the key issue: Netbeans is a java application. As long as you have a 64 bit java runtime installed, netbeans should happily run in that. There may be a native 32 bit executable that starts things up, but it'd be separate from the java runtime and won't prevent a 64 bit runtime from running. That's what I make of it, at least.
A successful API design takes a mixture of software design and pedagogy.
Not unless you are a real developer, which you're obviously not... (see, I can troll too!)
For me the gold standard will always be Intellij. I liked Netbeans the last time I tried it a couple of years ago, but it was too buggy for regular use (like creating thousands of temp directories for no reason). I use Eclipse for specialized development since many vendors will provide plugins that make it worth it (barely). But I always come back to IntelliJ for its more intuitive handling. It's simply the best IDE I've used in any language.
I didn't think so. A plugin it must be.
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
May not make sense to some of you, but I am trying to go completely 64-bit here (may sound strange, but string processing seems faster on it, even notepad.exe itself, by far, vs. 32-bit in native 32-bit OS environs no less - very noticeable!)
I'm going to go off-topic for a second to address your post. Firstly, preliminary research (I mean that) suggests that NetBeans is pure Java, so it will run in whatever JVM you have. Both 32- and 64-bit JVMs are offered, so it sounds like NetBeans will run in 64-bit mode. However, there is also information that suggests the NetBeans installer only supports the 32-bit JVM, so you'll likely have to install it with a 32-bit application, but can run it as a 64-bit application.
Regardless, I feel that you're a bit misguided about the nature of 64-bit architectures. Let me list for you the big advantages that 64-bit has over 32-bit:
So let's break this down. (1) means that applications that use huge amounts of memory (over 3 GB) at the same time will likely run faster. Most applications come nowhere near this, and NetBeans is no exception. Unless you're running enterprise applications or database servers, you shouldn't notice any change from this strength, and even then, only those applications need to be 64-bit to gain the advantage. You can use 32-bit NetBeans to build a 64-bit GlassFish application.
(2) means that your system's paging layouts and execution environment can take advantage of some of the offerings of the modern architecture for both security and efficiency. This is almost entirely handled by the kernel, meaning that if you're running a 64-bit kernel, you're fine. Actually, modern 32-bit kernels can also take advantage of 64-bit architecture security features, so either way you're good. A 64-bit kernel can easily run 32-bit applications, so (2) alone isn't a reason to favor 64-bit applications.
Finally, (3) means that certain operations dealing with gigantic numbers will be more efficient. It also means that compilers can do some slight optimization tricks on non-huge values. Unless you're running a math-intensive application (MatLab, Mathematica, etc.) , you shouldn't notice any difference from this.
I suppose, in summary, that your claim that even Notepad runs faster in 64-bit seems unlikely. Most applications gain no noticeable advantage being 32-bit over 64-bit. If you care about efficiency, use a 64-bit kernel, and run whatever applications are most convenient. If you want to read up on 64-bit architectures, check out Wikipedia.
Sadly, the Python plugin that worked in the 6.X series seems to be no longer available for Netbeans 7 ...
I've been doing a lot of web development lately with aptana which basically is eclipse just with a whole bunch of web-by add-ons and plugins. I must say that it is the best experience I've ever had with an ide for this kind of work. Supports code completion for jquery, dojo, plain javascript, css, html and a whole lot more out of the box. Add in some vi keybindings and I'm in dev heaven. Not sure if it will impress anyone's co-workers but it sure makes writing web pages fun.
The soylentnews experiment has been a dismal failure.
... as Enterprise Kissing ('twould be RESTful, I'm sure), you'd be receiving one of those from me right now.) In lieu of that... Kudos!
HAND.
To hell with this, where's my built-in Scala 2.8.x and SBT support? Instead I get PHP and "Guided installation to JDBC driver". Nice. Thanks.
The man who dies rich dies disgraced. -- Andrew Carnegie
NetBeans is honestly shit compared to VS.
Disclaimer: I use NetBeans and VS every day.
That's pretty much the rest of it (I get what you mean by JAVA runtime portions, I used the 32-bit one last round & on 32-bit Windows Server 2003). My question now is, what about other languages it supports (C++ iirc, & possibly others as well: If the base compilers can target 64-bit, is NetBeans 7 able to do so also?)
May seem silly, but I know little about NetBeans (even though I messed with it a bit in JAVA 32-bit).
Thanks for the assist here.
APK
May not make sense to some of you, but I am trying to go completely 64-bit here (may sound strange, but string processing seems faster on it, even notepad.exe itself, by far, vs. 32-bit in native 32-bit OS environs no less - very noticeable!)
Lemme guess. It particular shines on host file processing:)
Right now the 64-bit JRE is not an overall win unless you really need lots of memory per app. Java is really pointer-intensive, and doubling the size of pointers hurts. The 64-bit JRE does some on-the-fly compression to try to minimize the pain by using pointer compression (for instance, at most 40 or so bits of your pointers are used on current architectures, so it'll try to use that fact), but it's still gonna hurt.
Why would the word length and ABI of the apps you build in native-compiled languages using NetBeans depend on NetBeans? I'm sure you can just set it up to pass the relevant options to the compilers &c.
Yes, it can work with Java. VS is extremely pluggable. You can create a project type that calls the Java builds tools, understands the Java language, and so forth. Even the debugger is pluggable, although the only non-VS debugger I've used with it is also written by MS.
There's no place I could be, since I've found Serenity...
I prefer NB to VS, but it's hardly apples to oranges. NB does do C/C++, but it's not its strong point - Java is its strong point. I used to think that Visual Studio was the best IDE ever at about release 5, but since then I think all the main Java IDEs: Netbeans, Eclipse and IdeaJ have, well, eclipsed VS.
So do I and I think the exact opposite.
There's actually a downside to 64-bit as well: cache coherency is poorer, so unless you're actually taking advantage of 64-bit capabilities your Notepad or other simple app might actually be a little bit slower because cache misses will occur more often.
There's no place I could be, since I've found Serenity...
I love Netbeans and wish I didn't have to open up another window to get a full featured perl IDE.
I have been hoping for perl support for the past several releases and aside from rumors on forums
there hasn't been much to this.
Also, why hasn't someone picked up maintenance of the latex module!
Aaaarggghhhhh!
NetBeans is an IDE. It mostly doesn't give crap about what the compilers do, apart from producing an "understandable" debug information file with the executable, and the debugger being able to control the executable and extract/modify memory and registers. Even if, somehow, NetBeans didn't come with necessary debugger functionality needed to debug 64 bit executables, or if it didn't have the project setup dialogs expose the 64 bit target option, it should be an easy fix (perhaps less than 1000 lines worth of changed/added code).
When I last tried (a couple years ago) it was fairly easy to coax NetBeans to use a Zilog C compiler for the ez8 target. I only had to add a JNI blurb to expose Zilog's debugger dll, and some glue between that and rest of the IDE.
A successful API design takes a mixture of software design and pedagogy.
String processing work I've done in notepad.exe works faster in 64-bit Windows 7 than it does for me in Windows Server 2003, 32-bit... specifically, the edit menu REPLACE function & with the same size data and same file, everything. Any largish text file exhibits it for me in fact doing that operation. There IS a noticeable diff. in speed of it. Unless notepad.exe is rewritten better in Win7 64 than it is in WinSrv 2003, I am not sure what could be the cause here.
APK
P.S.=> Weird part is, the file itself it only around 40-50mb tops, not streamable afaik in text file data alone via notepad.exe, & well beneath 32-bit 4gb size limits (2gb memory to OS, & 2gb memory (both virtual) to notepad.exe by default)... apk
other languages that NetBeans 7 supports: Yes, the compilers "beneath" the mask of the NetBeans IDE may support 64-bit, but does NetBeans in former OR this version, in your guys' experience @ least, do as well as it does for JAVA, but instead say for C++ or the other possible languages NetBeans handles? For things like compiler switch optimizations, code completion (little things mostly, some bigger)...
This is hard to express to you - it really comes down to:
HOW COMPLETE IS THE SUPPORT IN NETBEANS, for 64-bit, FOR LANGUAGES OTHER THAN JAVA? ( in a nutshell, in bold)
APK
P.S.=> Thanks for your info. on this, & others replying also if I did not tell they the same... apk
String processing work I've done in notepad.exe works faster in 64-bit Windows 7 than it does for me in Windows Server 2003, 32-bit...
Specifically, the edit menu REPLACE function & with the same size data and same file, everything.
Any largish text file exhibits it for me in fact doing that operation.
There IS a noticeable diff. in speed of it.
Unless notepad.exe is rewritten better in Win7 64 than it is in WinSrv 2003, I am not sure what could be the cause here.
On cache coherency, that's really only about SMP/HT isn't it? Multi-CPU setups SHARING data in the cache areas...
What this boils down to is this (I must not be expressing myself well today):
HOW COMPLETE IS THE SUPPORT IN NETBEANS, for 64-bit, FOR LANGUAGES OTHER THAN JAVA? ( in a nutshell, in bold - I asked this of another replier here, & thanks for your time... )
APK
P.S.=> Anyhow - Weird part is, the file itself it only around 40-50mb tops, not streamable afaik in text file data alone via notepad.exe, & well beneath 32-bit 4gb size limits (2gb memory to OS, & 2gb memory (both virtual) to notepad.exe by default)... apk
emacs
I wouldn't be able to give a comprehensible feature comparison, but in terms of overall feel, NetBeans seems to be the Java IDE that is closest to VS. It has the same sort of "everything and kitchen sink" out of the box approach, with many rich project templates to get started, and a very nice Swing GUI designer that reminds me of WinForms one in VS (only NetBeans one generates flexible layouts, almost automagically!). Same for web development - you get a complete development stack set up right out of the box and integrated with IDE. If you come from VS, this is a nice thing compared to Eclipse where there are myriads of plugins for this and that, and then usually you still have to set up servers (for web) and emulators (for J2ME or Android) separately.
I use both, find them both excellent. I'd put them on a par feature and usability wise.
I really like NB (fast, unbloated, compact), but for GWT applications development Eclipse is superior.
http://en.wikipedia.org/wiki/Forth_(programming_language)
Are you trying to tell me NetBeans 7 supports that too?
APK
P.S.=> This is only a joke... or does it? apk
Initially - The majority portions of your reply (very detailed) I knew already. Thanks though, pretty accurate rundown.
However, yes, & I don't blame you - You may not believe it, but some operations I've done in notepad.exe in 32-bit OS environs (replace, from edit menu) is FASTER in the 64-bit model on Windows 7 64-bit.
Thanks, appreciate that. It's not whether or not I believe you so much as whether or not I can justify what you're asserting with (what I know of) the underlying technology. In this case, for example, I would expect the difference in performance to be much more tightly bound to the OS than to the application. For example, 32-bit Windows Server 2003 versus 64-bit Windows 7, you're testing different versions of Notepad on different operating systems. They have different scheduler optimizations, different background loads, and, to a significant extent, different internals. Not a good test!
32-bit Notepad on 64-bit Windows 7 versus 64-bit Notepad on 64-bit Windows 7 would be a test to run, and you would definitely have to do an accurate benchmark. I can't think, off the top of my head, why one would perform noticeably different then the other. One other poster mentioned cache coherency, but I tend to disagree in the common case, since regular (i.e., non-memory-intensive) applications share the same small virtual address space as their 32-bit equivalents.
otherwise... it's why I asked about NetBeans having 64-bit target capabilities for ALL languages the IDE supports... can NetBeans 7, do that (in a nutshell)... apk
So as far as I can tell, NetBeans modules (which add language support) are pure Java, and therefore will run in the JVM of your choice, be it 32-bit or 64-bit.
Cheers!
It is very good for java, but a bit hard to set up for C/C++ and I don't think it supports C#.
I personally use it for all of my coding as it's formatting and code completion features are very good (even for C and HTML) and I find it easier to use then other IDE's (although Visual Studio comes close).
null
Netbeans runs the same as you Java install. (if you have 64-bit java netbeans is 64-bit if you 32-bit java netbeans is a 32-bit app).
On windows you may need to download the platform independent version to run in 64-bit mode (can't remember).
Netbeans follows the standards for the language you are using for syntax checking and code completion, you specify the compiler/SDK you want to use for each project, usually netbeans auto-detects SDK install if you specify there installation directory.
Netbeans works with 32 and 64-bit compilers.
null
I can't stand it under Ubuntu. Netbeans does not use Ubuntu's Xorg fonts and it looks ugly and way out of place. Not only are the same fonts not used but they are not LCD friendly sub pixeled rendered in the same way. My guess is a hinting bug is in there as well. I reported this bug 2 years ago and they still have not fixed it claiming it was Sun's problem with their JDK.
It looks fantastic on Fedora.
Netbeans has got a bad rap because of this bug from Ubuntu users as it looked very Swingish style.
http://saveie6.com/
Tell Oracle I'm still not talking to them after what they did to OpenSolaris. He can take back his "Net Beans" -- that's HARDLY an apology.
My vim have HTML5 editing support 10 years ago!
See subject-line, & this was the line from your reply that helped:
"Netbeans follows the standards for the language you are using for syntax checking and code completion, you specify the compiler/SDK you want to use for each project, usually netbeans auto-detects SDK install if you specify there installation directory. Netbeans works with 32 and 64-bit compilers" - by HJED (1304957) on Thursday April 21, @12:17AM (#35889062) Homepage
Again, thanks. I was aware of the 32/64 bit part with JAVA, but I was mostly curious on OTHER languages' support (how accurate is it, how good is code completion. help files etc./et al) really... & I think your reply answers it best. C++ support was the one I was TRULY the most curious about actually...
APK
P.S.=> Now, I don't know why the heck an honest question from me was down moderated here, but there you are. It's slashdot... lol! apk
"For example, 32-bit Windows Server 2003 versus 64-bit Windows 7, you're testing different versions of Notepad on different operating systems. They have different scheduler optimizations, different background loads, and, to a significant extent, different internals." - by Jahava (946858) on Wednesday April 20, @11:27PM (#35888422)
If I were a "betting man"? That's the answer here I would wager... & I alluded to MUCH THE SAME, here. in response to another replier here:
"Unless notepad.exe is rewritten better in Win7 64 than it is in WinSrv 2003, I am not sure what could be the cause here." - by Anonymous Coward on Wednesday April 20, @08:21PM (#35886854)
FROM - > http://developers.slashdot.org/comments.pl?sid=2093064&cid=35886854
---
"One other poster mentioned cache coherency" - by Jahava (946858) on Wednesday April 20, @11:27PM (#35888422)
I wouldn't have "leaned to much" to that either myself, because iirc, it deals MORE with shared cache memory lanes/lines between MULTIPLE cpu's (e.g.-> SMP. or Dual/Quad Core etc. or possibly even HT (hyperthreaded) setups)... but, one never knows.
---
"Not a good test!" - by Anonymous Coward on Wednesday April 20, @08:21PM (#35886854)
Well, it really wasn't so much a "test", as an observation...
(AND, it was something I liked immediately/right-off-the-bat with Windows 7 64-bit, vs. Windows Server 2003 32-bit, because I do a bit of string processing oriented coding here in my spare time...).
APK
P.S.=> Above all else here though, perhaps? Thank you for your time & especially YOUR efforts... I don't understand WHY my post, with an honest set of geniune questions, was down-moderated either, but... that's life, & this is slashdot, lol... apk
And yet other silly "{vi,emacs} vs {IDE}"... Anyone who thinks {vi,emacs} allows a Java dev to be as productive as {Eclipse,IntelliJ IDEA,Netbeans} should go visit the nearest psychiatric hospital. Also, anyone who thinks the "editor" part of {Eclipse,IntelliJ IDEA,Netbeans} allows to be as productive for "text editing" as {vi,Emacs} should go visit the nearest psychiatric hospital.
I do have IntelliJ IDEA and Emacs always running simultaneously and configured to auto-synch files: I need to do something IntelliJ's better at (like refactoring on analyzing a partial AST [ie incomplete source code] to give me real-time warning about coding mistakes), then I'm under IntelliJ. I need to do something only Emacs can do (like, say, marking an area and increment by one all the integer found in this text area, then I'm under Emacs.
Anyone arguing he's "more productive" using only {vi,emacs,IntelliJ,etc.} is a fool.
Did they finally add virtual line wrapping? They promised it will be there in 7.0. It can be the most wonderful IDE in the world, without line wrapping it's next to useless. It's one of the most basic features, and both Eclipse and NetBeans don't have it, which speaks volumes about them.
Oh, and in case any imbeciles feel like they just have to open their mouths and say "you shouldn't need line wrapping":
* I don't always control the code from day zero, so it might have long lines when it reaches me. I can't justify purely cosmetic commits to the source repository.
* Sometimes you cannot split a line.
* Screens in use today vary from 17" 4:3 to 26" 16:9. Expecting "one size fits all" across this range is nuts.
* Formatting code as if it was meant for an 80-column printer or screen, in today's day and age, is idiotic.
Happy NetBeans 7 Day to you all !!!
I've used Netbeans for over 8 years. It's a great IDE (the best in my opinion) but someone clearly rushed this release out the door before it was ready. The release candidates and final release are unusable for daily use.
The great team behind Netbeans should have it all fixed within a month but I would avoid it for now.
I don't know WHAT the cause is, just that "it is". Others have discussed it with me here, and a couple guys have good ideas. Could be a few things in notepad.exe in 64 bit or the OS itself (even though the data doesn't come anywhere NEAR the size limits of 32-bit in 4gb (std. 2gb OS/ 2gb app split & 3gb app/ 1gb OS even "tweaked" via boot.ini switches)...
APK
P.S.=> Doesn't much matter. A few guys have answered my questions on NetBeans 7, & that's REALLY what I came here for anyhow... apk
I use NetBeans 6.9 at work every day for practically everything in our projects (mainly PHP, Ruby and SQL). It's a fantastic and powerful IDE, and very fast compared to Eclipse. The removal of Ruby really hurts though, so I won't be upgrading to 7 straight away. I will consider it once the plugin is ready to be used again after being handled by external developers: http://wiki.netbeans.org/RubySupport
It probably went faster because 64-bit-wide registers can hold more characters in them for comparison at once. Wider registers aren't just good for numbers. That's only a guess, though; I don't know how the string replace function is actually implemented, or if there was something special about the data you were working on.
Ccache coherency affects single-processor systems too. The larger your binary instructions, the fewer of them fit in a given cache line and the more often you'll need to go to memory. One advantage of x86 is that its multi-length instructions let a large number of the most common instructions fit into size that an ISA like MIPS would only be able to get a couple instructions into. 64-bit reduces that, somewhat (pointer addresses, etc.).
There's no place I could be, since I've found Serenity...
Never has a combination of words been this histerically ironic Netbeans is a Superb PHP IDE
"It probably went faster because 64-bit-wide registers can hold more characters in them for comparison at once." - by cbhacking (979169) on Friday April 22, @01:36AM (#35903782) Homepage
Could be... but, the "funny part" is, that none of the strings, individually per line, are longer than 105 characters long, which is as you know, FAR below the 32-bit addressability size limits, and so is the file ITSELF even, weighing in @ less than 50mb in size.
---
"Wider registers aren't just good for numbers. That's only a guess, though;" - by cbhacking (979169) on Friday April 22, @01:36AM (#35903782) Homepage
Oh, it's a decent enough guess... but, only 1 value @ a time can be "stuff into" those registers too, afaik, for comparisons etc. for REPLACE functions to work, so...
---
"That's only a guess, though; I don't know how the string replace function is actually implemented, or if there was something special about the data you were working on." - by cbhacking (979169) on Friday April 22, @01:36AM (#35903782) Homepage
It's probably a loop, "do until EOF" type stuff (end-of-file marker/trailer record), comparing the sought after term with the current term being read (character-by-character - from EACH LINE READ vs. the compared to term), so an equivalency can be tested for...
However - that's just "on a guess", myself. I've done similar enough things in code though & that's how I'd do it in fact.
(Good discussion, all-in-all: Thanks - it's ones like that that make you *think*, & bouncing ideas off others lends to that... "2nd set of eyes" & all that!)
APK
P.S.=> Hmmm, on this one:
"One advantage of x86 is that its multi-length instructions let a large number of the most common instructions fit into size that an ISA like MIPS would only be able to get a couple instructions into. 64-bit reduces that, somewhat (pointer addresses, etc.)." - by cbhacking (979169) on Friday April 22, @01:36AM (#35903782) Homepage
I always thought pointer "size" INCREASED going from 32-bit to 64-bit... apk
1st, see subject-line (you didn't reply for a good while so I was ready to "blow this off"). Secondly:
"However, the 8 characters in the 64-bit register are still TWICE as many as the 4 in the 32-bit register, so yes, I'd imagine some text/string operations could actually perform better when using 64-bit registers for frequent operations in a tight loop for, like, say, text comparison. Addressability had nothing to do with this particular point. Perhaps you misread." - by Anonymous Coward on Sunday April 24, @06:10AM (#35919910)
I don't know about "misread", all I know is I am supplying data for the conditions that are what's happening here... & the longest string is 105 chars long in any file I process (& they DO operate faster in 64-bit Win7 than they did in 32-bit Windows Server 2003).
NOW - on that note in "bold" above, IMPORTANT:
I thought you can do 254 char long items in 32 bit & not cross that boundary of 32-bit address space ranges? For example, filesystem naming on folders &/or files... they can go up to 254 chars in Windows!
APK
P.S.=>
"I'd imagine some text/string operations could actually perform better when using 64-bit registers for frequent operations in a tight loop for, like, say, text comparison." - by Anonymous Coward on Sunday April 24, @06:10AM (#35919910)
Well, that's what I've been SAYING here, the ENTIRE TIME no less (to a lot of ridicule no less much of the time... well, I know what I see & have SEEN, in this very specific string processing scenario with 32-bit Windows Server 2003 being SLOWER THAN Windows 7 64-bit)... apk
Emacs is an OS, not an text editor. Unfair comparison
-- dnl