Bob,

Got the answer:

€ alt+0128

Thanks for the help,

Bob,

It looks like a "c" with two lines through the middle, making it look like an "e":



Thanks,

EDIT...deleted

Don't even know what it looks like. Got a link that'll show an example of one?

Bob,

Is there a way to use the "euro" symbol in a post on iHub?

TIA,

Bob,

Here's the link to download NAPA from Intel:

http://www.intel.com/software/products/opensource/tools1/napa.htm

greg

Bob,

I have seen first-hand your desire to code as efficiently as possible, and I agree with your view.

I'll be interested to see what you think of this tool. Please post back here what you think.

Thanks,

greg

Thanks for the link, Greg. I'll definitely read it later.

I especially loved this quote, and the timing's interesting:

The bottom line: to fix a problem, you need to understand the problem.

The timing's interesting becuase I'd just written a post about solving a problem in seconds that'd been plaguing a company for several months. And it was basically done by correctly identifying what the problem was. And that's usually done by not only identifying what kind of problem it is (software? hardware? bandwidth? memory? CPU?), but checking the easy stuff first.

Kinda like when I worked for a while as a motorcycle mechanic who would go to the motorcycle rather than having it brought to me. I remember one bike that the owner had put a lot of time into trying to get running, and he literally got very angry when I got it running by replacing a fuse under the seat then handing him a bill for $45 (my minimum). I don't know if he was angrier about my having gotten the bike running in minutes when he'd been struggling with it for so long, or because he was charged $45 for those minutes. Probably both.

I'm one of those weird programmers whose biggest thrill isn't from adding new features. I love to add new features, but what really turns me on programming-wise is to tweak the last little bit of performance out of something. I happily spend hours doing lots of coding to decrease bandwidth utilization by 5%. Same with CPU usage.

It might seem inefficient to spend hours doing something that saves milliseconds, but when those milliseconds are being saved millions of times per month, it adds up and is well worth it.

Bob,

Here's an article on "NAPA" which I found interesting and thought I'd pass along. You may already have heard about this, but it looks like a neat tool. I was especially intrigued by the comments at the end of the article that the NAPA code was open source and the user could tweak it to their own requirements:

http://www.extremetech.com/print_article/0,3428,a=23680,00.asp

NAPA to the Rescue

March 6, 2002
By: Robyn Peterson

The only good web page, is a fast web page. With that assumption in mind, we can move on...
The most common complaint in any Webmaster's mailbox has got to be, "why is the site so &#@#% slow?" The truth is, most websites out there are bandwidth hogs. At ExtremeTech, we'll admit it--we're not guilt free in this area either. We all have something to learn.

As Web developers, we're all working so fast and trying so hard to be innovative, we're missing easy opportunities to optimize our sites for faster performance. On our high-speed connections at the office, we may not notice that we have a problem. But any user who dials in with a 56k modem (or slower) will bluntly inform us that we need to sign up our web site for a digital Weight Watchers program.

Prescribing a technical cure-all for slow websites is about as difficult as prescribing the right flu vaccine--it works in some cases, but in others, you're just out of luck. Design is always an issue. It's tough to balance a good design with fast performance--there are always trade-offs. However, if you truly want to optimize your Web site for long run, you'll need to look at not only your design, but how your design and code are delivered to your end user. (Note that we covered many of these design issues in our Web Accessibility story written by John C. Fish.)

On the back-end, if our servers aren't maximizing the available bandwidth or are averaging higher than normal latency, it truly will not matter how light your page is--your servers will deliver it at a snail's pace.

In this article, we'll look at the front-end and the back-end of your website keying in on different ways you can optimize both of these areas. In so doing, we'll add a new open source application from Intel to our toolbox called NAPA (Network Applications Performance Analyzer), which we'll use to pry open the virtual black box that is your web site (and the associated network usage).

The bottom line: to fix a problem, you need to understand the problem. Dig in to find out how to use NAPA to realize the potential of your web site--and then use our tips to acquire the speed you need to survive.

NOTE: Even if you're not a Web Developer or a System Administrators, NAPA is a blast to play around with. So, stay tuned in and get clued in on how to use NAPA solely for informational purposes--you may learn something. (Hint: NAPA might help you decide which browser is the best/fastest for you by analyzing your browser interaction with the sites you visit most frequently.)

Also note that the current version of NAPA runs on Windows 2000 only. .....

It's a fairly long article, but a good read.

greg

Another subject. I was surfing the web and came across this article: http://news.ft.com/ft/gx.cgi/ftc?pagename=View&c=Article&cid=FT3YADHDPWC&live=true&t...

Basically someone wrote some software to detect when someone is er... lying.

It would be an interesting thing to apply that stuff to the posts here on the stock forums to 'determine' the possiblity that someone is pushing a stock vs posting information about a stock....

what do you think?

Kinda/sorta.

I went through a lot of queries that really didn't need to fetch entire tables and made them fetch TOP 50 or whatever amount worked, instead.

read_msg will be a complete rewrite.

Since it's the remaining major culprit, I expect to address a lot of different things with the rewrite: Stored Procs, forcing SQL to handle locks my way (using NOLOCKS where warranted), and using more-selective SELECTs. <g>

I'm not in a big hurry, though. I think enough of it's tweaked now to make the timeouts a less frequent occurrence, though likely not rare yet. I'm going to clear the rest of the stuff off my plate then dive into read_msg. Once I'm done with read_msg, I should be done with performance tweaks for a while and can knock out some bugs and new features before going back to the optimization thing. You know, mostly CSS and stored procs across the site.

So didja finally nail that booger?

To kind of get the ball rolling, here's my current struggle. I think I've got a handle on it, but any ASP/SQL geeks out there are more than welcome to offer their opinion.

The site has been getting frequent timeouts. Specifically, web pages that don't load and instead give the "timeout expired" message. I haven't gotten enough cut and paste copies to know for certain, but I think the main culprit might be a particular SELECT statement in read_msg.asp. However, the trace that's currently running might be identifying boards.asp as the biggest culprit. Won't know for sure until I scrutinize the trace log tonight.

Both the SELECT statement I've seen bomb out via cut and paste, and the one that's being identified as a resource pig in Trace right now have at least one thing in common (that I've noticed so far): the SELECT statement specifically naming every field to retrieve (over a dozen) rather than using a "*". Oddly, when I tried changing it to "*" on my local setup, I got errors further down the script. Go figure.

I doubt the explicit naming of fields is really the problem anyway. It's not the angle I'm going to pursue first to try to tweak it.

I think the problem might instead be the WHERE clauses. I haven't checked yet (I will tonight), but it's entirely possible that the fields named in the WHERE clauses aren't indexed.

One of the fields can contain one of only two possible values and another can contain only one of 3. It's my understanding that you don't typically index such fields. Thoughts?

The field that contains 3 possibilities is used to identify what type of message is being looked at and to exclude private messages. I've got an idea on that one. It's looking for one value to exist in that field (which is a Text field, btw -- I'm thinking that could be a big problem) and I'm thinking that I should add a field (type Bit) to the table that's used to identify the message as either private or not.

I'll likely try that tonight as well as making it a Stored Proc to see if it can work a bit faster.

So, while I have my best friend (who's a major SQL Server geek) look at the server configuration, I'll try to tweak all queries so that none of them take more than 1k milliseconds to run. The first approach I'll use is trying to get them to do the fewest reads possible.