Castalia For Delphi 7

The latest version of Castalia, 2014.11, adds a very interesting feature, ' Show Debug Variables'. As you step in the code while debugging, you get to see the values where the variables are used. Truly in this case, a picture is much better than a description:Now even better for Delphi XE7 and RAD Studio XE7 customers, this feature is available for free with the updated version of Castalia, free for registered users, at.So if you own Delphi XE7 and haven't downloaded Castalia, it is time to do it. If you have already downloaded it.

It is time to get the new, updated version. For more information, head to.posted by@. Castalia for Delphi XE7 Users, Now with Show Debug VariablesIt is interesting - in many ways better than thebuilt in debugger that quickly forgets variables asthey drop out of scope.However, as a first run it is pretty glitchy.Still, because of how much I have to turn off inCastalia to keep it from 'helping', I frequentlycan't run it for more than a few hours withoutuninstalling it anyways.Still, if I can find a way to turn off the rest ofthe 'help' that drives me away from it, the debugrendering is worth having.Comment by C Johnson on November 29, 17:39.

If you have enough guts to keep Castalia enabled and have Delphi Berlin or higher, then you can use this shortcut: WayBack Tip: Use Ctrl+W to select content in the IDE code editor. Place your cursor some random piece of code, preferably deep in code that have nested block. Lars Fosdal - Google+ -jeroen. Kastalia Boutique Hotel is located in Delphi. The area's natural beauty can be seen at Parnassos National Park and Corycian Cave, while Delphi Museum and Delphi Archaeological Museum are cultural highlights. Spend some time exploring the area's activities, including skiing and skiing lessons.

I’ve just released the newest version of my enhanced code editor for Delphi programmers: 2013.4.Castalia helps Delphi programmers visualize their code clearly, and write better code faster.What’s new in Castalia 2013.4:. Fixed: Error CCI 2738 when writing code using the Android personality. Fixed: Structural highlighting doesn’t work correctly for class static methods. Several small performance improvements in speed and memory usageCustomers with a current subscription can download Castalia 2013.4 right now at the.Everyone else can try it out at. Last week, I wrote a somewhat lengthy describing a number of things I’ve done recently to improve speed and responsiveness. Several of you asked for more information about the instrumentation that I used to measure performance times. In this post, I’ll describe two techniques for measuring the speed of a segment of code.

The very easy wayIn a nutshell, measuring the speed of a segment of code is incredibly easy. You look at what time it is when the code starts running, then you look again when it’s done, and the difference tells you how long it took the code to run.So, the only thing we need to figure out how to do is how to “look at what time it is.” I used two mechanisms to do this. The first one is the function. GetTickCount is a Windows API, not part of the VCL.

It simply returns the number of milliseconds that have elapsed since the computer was started up. Here’s an example of how to use GetTickCount: varStartTime, EndTime, Delta: Integer;beginStartTime:= GetTickCount;//Code you want to measure hereEndTime:= GetTickCount;Delta:= EndTime - StartTime;//Show Delta so you know the elapsed timeend;It’s really that simple. This will tell you how many milliseconds it took to execute the code in begin measured.There is one problem with GetTickCount, however: It’s not reliably accurate for timespans less than about 15 milliseconds.

Zebra LifeGuard updates are a convenient way to receive extended security support, predictable periodic security updates and legacy OS security support. Available for select Zebra Android mobile computers with a Zebra OneCare active contract. Subscribe to LifeGuard Updates. Search Knowledge Base. Discussion Forums. Warranty Lookup. Uninstall ZebraLink Multiplatform SDK 9.5 for Mac can be downloaded from our website for free. This Mac app was originally designed by ZIH Corp. Uninstall ZebraLink Multiplatform SDK for Mac is included in Developer Tools. Our antivirus scan shows that this Mac download is safe. The most popular version of the software is 9.5. Zebralink firmware downloader for mac. The ZebraLink Design tools create flexible and optimized documents. ZebraDesigner™ Software helps you quickly design labels for your business needs. Zebra Utilities for iOS. The Zebra Utilities enables printing from iOS devices. Zebra Utilities for Android. The Zebra Utilities enables printing from Android devices. This software for Mac OS X was originally produced by Urs Heckmann. The Zebra installer is commonly called Zebra25MacInstall.zip. Zebra for Mac is categorized as Audio & Video Tools.

Above that, it’s fine, and is OK for an approximation to figure out the big bottlenecks might be, but what if you want to measure the execution of a function that’s a lot faster than 15ms already? The slightly less easy wayThe next way takes just a little bit more work, but not much. Windows includes a mechanism called, intended for exactly this purpose. In working with Castalia, I used the function exactly the same way as GetTickCount: Get the time at the start of the code I’m measuring, get the time again at the end, and record the difference.While GetTickCount measures time in milliseconds, QueryPerformanceCounter’s measurement of time is hardware-dependent. In fact, QueryPerformanceCounter relies on the CPU having a high-resolution performance counter, and won’t work if your CPU doesn’t have one (as far as I’m aware, all modern desktop CPU’s have one, so you probably don’t need to worry about that).Technical historical aside: At its inception, QueryPerformanceCounter was intended to be an easy way to access the Pentium CPU’s RDTSC instruction, which returns the number of CPU cycles that have elapsed. MultiProcessor/MultiCore/Hyperthreaded architectures have made measuring CPU cycles unreliable, so now RDTSC simply measures some very small unit of time.Because it’s measuring much faster units of time, and needs much larger numbers, QueryPerformanceCounter requires an Int64. Here’s an example of using QueryPerformanceCounter to measure the time of some code: varStartTime, EndTime, Delta: Int64;beginQueryPerformanceCounter(StartTime);//Code you want to measure hereQueryPerformanceCounter(EndTime);Delta:= EndTime - StartTime;//Show Delta so you know the elapsed timeend;That’s very simple too.

We can use those numbers for comparisons as-is, but I like to translate them into milliseconds in order to get a more familiar unit of measure that’s also comparable between different systems. To do that, we need to know exactly what unit of time QueryPerformanceCounter is measuring.

To get that information, we use the function.QueryPerformanceFrequency tells us the number of units per second that the high-resolution performance counter is using. It also takes an Int64. We only need to call it once per application, since it doesn’t really change (actually, it can if the CPU gets throttled for power/temperature reasons, but lets assume that it won’t happen while you’re running your tests).

To find out how many high-resolution units are in a millisecond, do something like this: varFrequency, UnitsPerMS: Int64;beginQueryPerformanceFrequency(Frequency);UnitsPerMS:= Frequency div 1000;end;Then you can divide your performance Delta by UnitsPerMS to find out how many milliseconds your code is actually taking to run. For example, in a VM on my Sandy Bridge i7, Frequency = 3,579,545. That means there are approximately 3,580 “units” per millisecond. If the QueryPerformanceCounter delta on some code is 385, that means the code took 0.1 milliseconds to run.That’s a MUCH higher resolution than GetTickCount Why not use QueryPerformanceCounter all the time?There’s one problem with QueryPerformanceCounter: It can be very slow compared to GetTickCount. On the same Sandy Bridge i7 as above, with Windows 7, QueryPerformanceCounter is well over 100 times slower than GetTickCount.This probably only matters if you’re measuring the speed of code that includes calls to QueryPerformanceCounter.

This is easy to do (and not realize you’re doing) if you measure the time of a function that calls another function which you’re also instrumenting. That’s just something to keep in mind and be careful about.If you’re wanting to ship instrumented code to users, be very careful about overusing QueryPerformanceCounter to do it; it can actually negatively affect the speed of your code. Showing the informationIn the code examples above, I sort of skipped an important step, which is actually displaying the delta values. There are a few ways to do that, each with their own set of caveats.For a VCL Forms application, the easiest is probably with a call to ShowMessage(IntToStr(Delta)). This shows you the number quickly, but it also blocks the application, and would be downright impossible to manage if you were measuring each iteration of a large loop or each level of a deeply nested set of function calls.Another alternative would be the API.

OutputDebugString logs any string to the debugger. In Delphi, this string will appear in the “Messages” window in the IDE. Use this when you want to record a lot of data as you use your application, then analyze it later. Beware, however, that this has the same caveat as QueryPerformanceCounter: It’s not a very fast function, and overusing it can have negative effects on your code’s performance. If you use calls to OutputDebugString in your performance-sensitive code, you’ll definitely want to remove them in your release build.Finally, you could store the data internally, then show the result once using one of the mechanisms above. For example, if you were testing the speed of each iteration of a loop, and the loop was running 10,000 times, you could create an array of 10,000 integers, put the Delta from each loop in each one, and then display them all at once however you like (or, calculate an average and display that). This is the approach I used most with my recent work on Castalia, and it worked very well.

Final thoughtsIf you want to improve performance, you have to first measure performance. Using GetTickCount or QueryPerformanceCounter, you can measure the speed of your code with varying degrees of reliability and resolution. Choose the one that best meets your needs. Appendix A (Added about 7 hours after this post was initially published)Reader Alan C posted a comment below pointing out the utility class, which encapsulates all of the above into a Delphi-friendly class. Because Castalia is compatible with Delphi versions back to Delphi 5, and TStopWatch was added in Delphi 2010, I didn’t use it in the work I’ve done with Castalia this year.TStopWatch does indeed encapsulate the functionality described above, defaulting to use the high resolution timer if it’s available, and using GetTickCount otherwise. Still, even if you use TStopWatch, it’s good to understand the limitations and performance impact that it can have. Thanks Alan for pointing this out!

This year’s releases have seen huge improvements in performance. Because performance optimization is important to Delphi programmers, and something we all have to face at some point, I’ve decided to write about what I did to get those performance gains. I hope this will help you to improve the code you write too. Identifying the Problem The Qualitative ProblemThere had been “qualitative” concerns about Castalia’s performance for a while. Users would write things like “it’s slow” or “it feels sluggish.” Talking to users who had these complaints, I learned that the performance complaints were in two areas:1.

The code editor would lag behind when scrolling using the mouse scroll wheel2. The code editor could lag behind when typing code, if you typed sufficiently fast enough.So, at the beginning of 2013, I determined that I was going to get the bottom of these issues and fix them once and for all, even if I had to rewrite the whole parser in hand-optimized assembler code. The Quantitative ProblemThe secret of real performance improvement is measurement. I needed some way to compare Castalia’s performance to the performance of Delphi without Castalia, and then to measure whether the improvements I would make were actually having an impact. Qualitative descriptions like “slow” or “sluggish” aren’t things you can compare; I needed real numeric data.I spent a day writing some code instrumentation. In other words, I wrote a simple framework that would allow me to measure the exact time that certain operations took. I could time the execution of a function, a single line of code, or response to an event like a key press, mouse click, or a paint event in the code editor.Next, I gathered data on current performance.

First, I ran Delphi with only my instrumentation enabled, and no other Castalia features. This allowed me to see how fast Delphi responds to key presses, scroll wheel motion, and other events.Then, I enabled all of Castalia’s features, and ran the exact same tests, collecting data to see how Delphi responded to those same events, but with Castalia doing its thing along the way.Comparing these two data sets gave me the difference in performance between Delphi by itself and Delphi with Castalia. Now, instead of words like “slow” or “sluggish,” I had actual numbers. This turned a qualitative problem into a quantitative problem, with good measurements, and things that can be measured can be improved! Finding BottlenecksThe next step, now that I had this data, was to figure out where the problem actually was. The question I needed to answer was “ What code is actually creating the problem?”I have to admit, I started down the wrong path on this.

I had gotten a lot of emails from users saying things like “It’s slow because the parser runs after every keystroke,” and “The parser isn’t fast enough for this enormous file I’m working on.” Those are very reasonable complaints, and since certain parts of the Castalia parser do need to run for every keystroke in the editor, it had better be incredibly fast, even on very large files.After several days of work, I had to come to the conclusion that the parser wasn’t the problem. The parser was already blindingly fast. It could churn through huge files in single-digit milliseconds. I even wrote a quick program to generate syntactically correct gibberish source code files, and had it generate a file of over 300,000 lines of code, which the Castalia parser handled in just a few milliseconds. The parser was plenty fast. The problem had to be somewhere else.In hindsight, my next strategy was much smarter.

I commented out the initialization code for every Castalia feature except the code that was necessary for the performance measurements. Then, I gradually re-enabled features one at a time, running the performance tests and collecting data again.When enabling a feature created a spike in the response time to some event, I would add more and more instrumentation code as needed, until I had narrowed it down to some specific thing that I could work on optimizing. Then, I would work through that bottleneck, bringing the performance time down as low as possible. Sony vegas pro 16 serial number reddit. Fixing the Problem(s)Sometimes, when we’re fixing bugs or improving performance, we find a single fix that solves the problem.

There have been many times where a seemingly complex bug was, in-fact, the result of a single-line error that only needed a single-line fix.Unfortunately, there was no single fix that solved all of Castalia’s performance problems. The huge gains in performance that have happened this year are the cumulative result of a number of big improvements. There was one that was bigger than all the others, but it certainly wasn’t a small single-line fix. More on that laterFor the remainder of this post, I’m going to outline a few specific bottlenecks that existed, and how I fixed them. Getting Source Code from the EditorCastalia has a function called GetSourceFromModule that gets source code out of the Delphi editor so Castalia can do things with it. This routine was written years ago, before the IDE supported Unicode, and Unicode support had been rather inelegantly shoved in.