In Flex I have a lot of Move effects and AnimateProperty effects.
What I have found in several different places in my code is that far too frequently the effect stops halfway through for no apparent reason.
I have found this in numerous places in my application and it occurs whether or not I am doin something particularly complicated.
Had anybody else experienced this issue?
I have not experienced this problem specifically but you might want to look at the Parallel () and Sequential to make sure that it isn't starting another effect before the first one completes.
This problem may be a byproduct of your app trying to do too much at the same time and the framerate suffering and so it is making your transitions choppy. You can either lengthen the duration of the transition or try to simplify your app to do less. HTH
Related
I'm trying to optimise a html parser for a Roku application I'm helping to develop. The parser currently takes too long to parse the data (8 seconds) and it does this by recursivly traversing the children of each tag encountered within a for each loop.
parser (nodes):
for each node in nodes
if node.isTag
parser(node.nodes)
else if node.isBlock
text.push(node)
something akin to that, although much more convoluted! I'm assuming it's slow because it's recursive and there is no tail recursion optimisation on the platform etc
I'm not too sure how to implement a stack to remove the recursiveness from this - I've tried using GoTo but that didn't seem to work :/
Can anyone provide some insight, and or whether you think the problem might be caused by the recursion?
What are you trying to achieve?
Some boxes are slow, there is only a certain amount of optimisation you can apply. If you need to parse the whole document, it usually takes what it takes. We had similar problem, app froze for a few seconds, looking like it's crashed but we got around it by displaying asynchronous spinning icon.
When I started working on my project I didn't really care so much about organizing my CSS file, but then I kept on adding ad-hoc selectors. Now I have 3048 lines of CSS code. I know I need to spend some time organizing this stuff and I know it will be much shorter once I do that since there's really a lot of redundancy.
But currently it's working fine (as it seems at least), and I just want to get the product out the door as soon as possible, so I was wondering, is this OK to have a long CSS like this and what are some of the critical drawbacks if any?
3048 lines isn't that bad, but it could be reduced; I'll give you benefit of the doubt and assume that you have a fairly complex site.
Super long CSS files start encountering problems in IE, which can only take a certain number of rules before it starts ignoring the rest.
Also, the longer the file, the more time it takes to parse - thus the longer it takes for your webpage to load.
Of course, with more rules comes more memory usage too.
That's about it, really.
It's okay if you don't mind gaining a reputation for being sloppy. That alone ought to be considered a "critical drawback". It takes no time at all to run it through a minimizer if you're sure that what you have currently is working.
As above, anybody looking at your website thinking about offering you a design opportunity might decide that you're sloppy and not make the offer.
It might take a few milliseconds longer for the client to parse.
It'll take half a second longer to load for people stuck on 768k DSL lines (there are still lots of those around).
Readability and the subsequent negatives.
Size. I mean since it is sent to the user, the longer it is the more time it will need (ofc with modern connection this is not a huge issue).
Consider Css language supersets like LessCss. It will dramatically decrease the complexity and increase productivity.
Also minifiers will help decreasing the size, with the trade off on readability, so minify only what is sent and not the code you are working on.
I started using Redcar a couple days ago as my primary text editor for programming on my Ubuntu machine. It's definitely a buggy software, and it's obvious that it's still in development, but overall I like it more than anything else I've come across. That said, I just discovered that I apparently can't do any more than 10 or so undos with the software. Even worse, I wasn't able to figure out any way to change this limit. This is kind of a dealbreaker for me, since I routinely write lots of code that I then choose to revert to something I had only a minute earlier.
Does anybody know if there is any way to raise this limit? Alternatively, does anybody know any other comparable text-editors for Linux? One of the most important features for me that any software I use needs to have is the ability to show me where a partner bracelet/bracket/parenthesis is when I move the cursor (or rather, whatever the keyboard equivalent of the cursor is called) onto it. I'm writing software that uses lots of callbacks, nested if statements, and nested loops, so I need to be able to easily tell where corresponding structures are in my code.
Best, and thanks in advance for any responses,Sami
friends,
I know ADG related questions generally get ignored because "it's a crappy component". Indeed, it is not one of my favorite pieces of code ever, but I'm stuck with it and have been working (pretty hard) at optimizing its performance. Turns out there's a fair amount of stuff one can do to make things go fast. One thing I've been stuck on, though, is not to optimize adding an element to the underlying dataprovider. Say you want to add a row to the ADG using a addChildAt call on the DP. All seems well but the operation is so slow - it's unbearable. Now, I realize that the ADG may need to redraw all the stuff below the line added, but seriously, in 2011 that should not take a load of time and 100$ of my CPU. Does anyone know what may be the main culprit?
Note: I'm able to catch the CollectionEvent of kind "add" and not deliver them to the ADG, which I thought would do the trick, but the ADG still updates and takes forever to do so, so I'm guessing there's something else somewhere else.
thanks for any tips!
f
ADG is the main culprit. Abandon all hope, ye who use the AdvandedDataGrid... Have you checked through it's source code? It's atrocious on sooo many levels.... Even if you find the culprit and come up with a fix, almost all real methods and properties are marked final and private, so that you simply can't override it's type of behavior.
It's a crappy answer, but I still stand behind it...
Q:
Lately ,i asked for testing a code ,,to detect the bugs and fix the problems ,,i find many problems ,, but the main problem here is the code it self ,, spaghetti code many many code lines and the tracing to fix problems is so difficult ,, plus some code is copied and pasted from the internet as it is without any modification,, no documentation is possible to this code,,the performance is so bad due to the heavy using of viewstate in every thing,, and it takes me a lot of time to fix the problems ,, and iam afraid of after all this time still other bugs may appear in the future .. how to handle this case ,,any advices concerning this issue will be a great help.
Start refactoring. This will not make only the code better readable it will also give you a btter understanding on how it works and what it does.
That's a very common situation - software was developed for some years and by many different developers and now you have to support it. You should fight the will to throw it away and rewrite the whole application - it is a big effort and chances are big that you will do many mistakes that are already fixed in bad code. See Joel article for more explanations.
In my experience the best way is to refactor the code. However it involves writing a lot of tests - unit, automated acceptance - and it will take almost the same time as rewriting, but it will be less pain
I think the mentality for working with spaghetti code is summed up quite well in Refactoring by Martin Fowler.
The picture that comes to my mind is surgery: The entire patient except the part to be operated on is draped. The draping leaves the surgeon with only a fixed set of variables. Now, we could have long arguments over whether this abstraction of a person to a lower left quadrant abdomen leads to good health care, but at the moment of surgery, I'm kind of glad the surgeon can focus
Basically what that means is start small, and update a single part of the code at a time. Little changes will add up to good, structured code in the future.
Of course, if there are major problems with the entire architecture, you may have to heed Cybernate's advice and start from scratch (unpleasant as it may be).
I would also write unit tests as well as refactoring as codymanix said. This does a couple things:
As you refactor, you will have some check that your refactoring won't break things.
Writing the tests is a good way of learning the domain knowledge embedded in the code.
Of course, there is an inherent catch-22 with adding unit tests to spaghetti code: it is usually hard to unit test, and you need to refactor it to be able to make it testable. But if you go bit by bit and start with the low-hanging fruit, usually you can make it readable.
Scrap the existing code and start afresh.
That involves lot less effort comparitively.
If that's not a possible option start with Refactoring using tool like ReSharper that will give a good start.